 |
|
| |
|
|
|
|
|
|
|
In case you haven't heard through some other channel already, Twisted 8 is out. In addition to numerous fixes and features, this release also includes a new release system for Twisted itself; this (hopefully) means that we won't have another year-long release drought. We're planning to do another release in less than 3 months. This means that new Twisted features will be available faster, but it also means that if you're writing some software that uses Twisted, upgrade now! We try very hard to make sure that each new release is mostly compatible with the one that comes before it, so that your upgrade should be painless. Especially if you have good unit tests. However, this compatibility doesn't extend infinitely. There are at least a few twisted developers who would really like to drop some of our years of accumulated cruft and break compatibility with older versions. If you upgrade now, your migration process will be gradually fixing a few deprecation warnings. If you wait for 3 or 4 more minor releases, upgrading all at once will mean that anything which has changed will start off broken, and your tests might not even run until you've fixed a bunch of things. Of course, by "will", I mean "should" - we're not perfect, but we'll fix upgrade issues in micro releases if you find them and report them.
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
Some library maintainers, when faced with the impending incompatible changes in Py3K, decide that it's time to burn their library down and start over with a new, incompatible version. "Python is changing", they say, "so people are going to have to do a bunch of maintenance anyway. What a great opportunity to force them to do all that maintenance that they should be doing for our library too!" I'm saying it's wrong. But don't take my word for it: Guido says it's wrong. Before it became cool to do it, Martijn Faassen was saying it was wrong. Guido didn't just blog that it was wrong, though. He was so concerned that this message get out publicly that he repeated himself in a mailing list message to python-dev to make sure that people who don't read blogs would get the message. This might strike some library maintainers as unfair. If Py3K is just breaking compatibility, why can't you? First of all, even if Py3K were really "just breaking compatibility", there is still the issue of careful timing. You should read Guido's post and understand Ima Lumberjack's plight; he explains it exactly as I would. When your users are doing maintenance to upgrade something, they only want to upgrade one thing, so they know what's going wrong when they encounter problems. And if you're making incompatible changes, they will encounter problems, regardless of how cool and well-documented your new API is. But, if you look closely, you will find that there's another reason that your library doesn't play by the same rules that Py3K does. It's because Py3K is actually doing a lot more than just breaking compatibility. I've been a critic of this effort in the past (and I still occasionally grumble about a thing or two) but the bottom line is that the core Python team is not just willy-nilly breaking stuff. Let me enumerate the huge amount of work they're doing to make sure that people can have a reasonable migration experience to Python 3: - The Python core team have written and are maintaining a source-to-source translation tool to assist in the transition. Does your compatibility-breaking project have source-to-source translation, or in fact any tool support for migrating between different versions of the library?
- The Python core team are developing a compatible backport of 99% of their features: Python 2.6 is effectively "python 3 lite"; you don't need to upgrade all the way to the incompatible version to get a lot of the new features. Does your compatibility-breaking project include a (at least mostly) compatible backport of all of your new features to an actively developed, "older" version?
- The Python core team is providing long-term support for the previous version so that people can migrate at their own pace and not be left out in the cold. Is your compatibility-breaking project planning to provide a decade worth of bugfixes, security patches, and feature backports to your older versions?
- The Python core team is providing comprehensive deprecation warnings explaining each new feature, and how you get there from the old feature. Is your project going to provide documentation like that?
It's also worth noting that Python's dependencies are not going through any kind of compatibility earthquake while they're doing this, so they are not in the same position that you (as a Python application author) are. So, if you answered "yes" to all four of those questions — you still don't have the same excuse that Python does, because their dependencies are not changing incompatibly. So don't do it. But if you were thinking about breaking compatibility at the same time as a dependency, then you probably didn't. Of course, you can drop deprecated stuff and break compatibility if your user community will tolerate that. Just don't do it in the same version where you decide to support Py3K. Users should have the ability to get a compatible version that will work in 2.x and 3.x so that when they translate their own source code, they don't have to learn new methods right at that moment.
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
I'm a big fan of Nine Inch Nails. Not quite to the degree of buying every Halo, but I have a number of his albums. So of course I've been intrigued by his latest offering. Today, while looking at Nine Inch Nails "Ghosts I-IV' website, I noticed an interesting bit of information: We have SOLD OUT of the 2500 Limited Edition Packages.
My great-uncle is fond of a saying. "It is better to be rich and healthy than to be poor and sick." Seeing this, I was reminded of it. It's not quite as catchy, but it's better to be customer-friendly and a huge success than reviled as corrupt and a failure. The music and movie industries have been telling us for the last few years that digital restrictions are required in order to save their businesses from destruction. Well, Mr. Reznor has proven them wrong quite dramatically. Before I continue, let me address an obvious objection up front - I realize he's a superstar. However, the spokespeople for the RIAA that support their claims are also superstars: Lars Ulrich is hardly a starving artist laboring in obscurity. I'm not saying everyone can do what he did, only that the people who are already rich in the music industry can continue to be rich without the bullshit that they claim is critical. The "Limited Edition", for those of you not up on the latest NIN happenings, is a three hundred dollar version of the album, containing a bunch of extras and a signature from Mr. Reznor himself. The full album, in lossless, non-restricted format, costs five dollars. There were 2500 copies of the limited edition. Let me emphasize for those of you who might not be quite as up on the terminology that "lossless" formats (which NIN is selling for $5 here) are the highest quality format that it is possible to distribute over the internet. Other music producers, out of fear for eating their CD revenues, have mostly refused to provide digital copies of their music of this quality. Also, to compare pricing: Apple typically charges 99¢ for a DRM-free song: it's not lossless, but it's 256kbps, which is fairly high quality. (I would not believe it if someone told me they could hear the difference, but there is a marginal difference in the perception of value here.) There are 36 songs on "Ghosts". $5 is roughly 14% of $35.64. So now that I've established that NIN is selling higher quality goods, in a customer-friendly way, for a fraction of the price of the competition, let's do some math: - march 6, today,
- minus the march 4th (the date that the "ghosts" website became fully operational (according to wikipedia),
- is two days, times
- 2500 copies
- times 300 dollars
- equals SEVEN HUNDRED AND FIFTY THOUSAND DOLLARS IN TWO DAYS.
Trent has now proven that if you are a superstar, you can make three quarters of a million dollars in two days, on a ridiculously expensive premium edition alone. This is to say nothing of the people who bought, and continue to buy, the $75 version, the $10 version, or the $5 version. This says nothing of the people who are buying it through Amazon. Coincidentally, it also proves that you don't need any RIAA thugs to help you do this, or "market" your work, assuming people already know who you are. You just need a web server, and a swimming pool big enough to put a million dollars.
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
I've previously blogged about twisted.python.modules, but it assumes you know about another API inside Twisted, twisted.python.filepath. Unfortunately this module is rather under-documented and under-publicized, despite being extremely useful. Unlike a lot of Twisted, much of the code in twisted.python can be extracted and used by itself, regardless of whether the program in question is networked or even event-driven. This is especially true of FilePath, which is completely blocking, although sometimes I wish there were at least a version of it that wasn't. A common sort of script that deals with a filesystem is to open each file in a directory hierarchy with a given path and do something to its contents. For example, let's write a program that prints out a list of all Python modules (with a .py extension) in a tree which contain shebang lines. Here's the script using good old os.path: import sys
import os
def os_shebangs(pathname):
for dirpath, dirnames, filenames in os.walk(pathname):
for filename in filenames:
fullpath = os.path.join(dirpath, filename)
if (fullpath.endswith(".py") and
file(fullpath, "rb").readline().startswith("#!")):
yield fullpath
def os_show_shebangs(pathname):
for path in os_shebangs(pathname):
sys.stdout.write("%s: %s\n" % (
path,
file(path, "rb").readline()[2:].strip()))
if __name__ == '__main__':
os_show_shebangs(sys.argv[1])
Pretty normal looking python code; not too much wrong with it. At 20 lines and 596 characters long, it's not too complex. Now let's have a look at a similarly idiomatic version using FilePath: import sys
from twisted.python.filepath import FilePath
def shebangs(path):
for p in path.walk():
if (p.basename().endswith(".py") and
p.open().readline().startswith("#!")):
yield p
def showShebangs(pathobj):
for path in shebangs(pathobj):
sys.stdout.write("%s: %s\n" % (
path.path,
path.open().readline()[2:].strip()))
if __name__ == '__main__':
showShebangs(FilePath(sys.argv[1]))
At 18 lines and 471 characters, it's almost exactly 20% smaller than the version that uses os.path. However, a small space savings is hardly the most interesting property of this code. The advantages over the version that uses os.path: - It's easier to test. You can use a fake FilePath object rather than needing to replace the whole "os" module and the "file" builtin.
- It's easier to read. You need fewer names; rather than os, os.path, and builtins, the code talks mainly to one object.
- It's easier to write. How many of you honestly remembered that "dirpath, dirnames, filenames" is the order of the tuples yielded from os.walk?
- It's easier to secure. If you wanted to allow untrusted users to supply input to the os.path version, you need to be very, very careful. What about "/"? What about ".."? With FilePath, you simply supply the input to the 'child' method, and...
>>> from twisted.python.filepath import FilePath
>>> fp = FilePath(".")
>>> x = fp.child("okay")
>>> y = fp.child("..")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "twisted/python/filepath.py", line 308, in child
raise InsecurePath("%r is not a child of %s" % (newpath, self.path))
twisted.python.filepath.InsecurePath: '/home' is not a child of /home/glyph
>>> z = fp.child("hello/world")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "twisted/python/filepath.py", line 305, in child
raise InsecurePath("%r contains one or more directory separators" % (path,))
twisted.python.filepath.InsecurePath: 'hello/world' contains one or more directory separators
- It's easier to extend. As of revision 22464 of Twisted (i.e. the next release) you can replace twisted.python.filepath.FilePath with twisted.python.zippath.ZipArchive, and this exact same code can operate on zip files.
Not only does FilePath provide these benefits, it has very few dependencies. Even if you don't like Twisted much, you can use twisted.python.filepath by copying only 3 modules into your project (twisted.python.filepath, twisted.python.win32, and twisted.python.runtime) and twiddling the appropriate imports to be relative. Since FilePath is only one import for your code, and mostly consists of method calls, it will easily work with Twisted's version or your own. So, share and enjoy!
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
So, as you may already have heard, we did a thing. While I've been able to tell a few people, I've been waiting to talk about it publicly for a while. We've gradually begun to launch Blendix. Blendix aims to be the one site that you need to visit every day to tell you what's happening in your world. Right now, it's an aggregator for various kinds of data around the web. You can pull in the usual suspects (RSS, ATOM), but it's a bit more than just an RSS aggregator: today, it understands a few more specific things (last.fm tracks, amazon wishlists, yahoo weather, flickr photos), and lots more are planned. Although I'm practically bursting with awesome ideas for its future development, I will try to refrain from commenting too much on those plans. As I've said before, software is like frisbee — predictions more specific than "hey, watch this!" can be dangerous :-). However, since I know it's the first thing you'll all suggest, I can say that yes, there will be richer integration with social networks. In brief, it works like this. You log in, and you create some people. Some feeds may be automatically discovered based on their email addresses, and you can add your own. Maybe you subscribe to some people: if you're looking for one to subscribe to, may I suggest " Glyph Lefkowitz". I hear he's pretty interesting. Finally, you visit your "dashboard" page, which — thanks to the magic of Athena — will update whenever blendix detects that one of the people you maintain or are subscribed to publishes some new data. You can expect to see more of that magic as it develops. A word of warning, though: it doesn't work with Safari (or IE, but I don't imagine that a lot of you are using IE). We're working on it, but for the time being, Firefox is strongly recommended. (Firefox for the mac works fine.) Most of the work involved in supporting Safari is in Nevow, which is all open source, so if you are familiar with these sorts of problems, please submit patches! This is our first live, fully public deployment of a Mantissa server, and I'm really glad to have it out there. We are, of course, working through the usual kinks of getting our first batch of users ("beta" isn't a web 2.0 buzzword for nothing), but I'm fairly pleased with it so far. Blendix itself isn't open source — yet. We've mainly been keeping the product as a whole behind closed doors as a matter of expediency. We didn't want to support an API that was heavily in development. However, one of my goals as we get closer to a bigger launch is to get enough of the code out there for you folks in the community to write extensions and improvements for it. There's already enough for some things (like supporting Safari!), even at the application level. For example, a big chunk of Blendix is the " Person" object, which is available in the public Mantissa code, along with UI for editing, browsing, and viewing. I'm really glad to have something "out there" to share with you all, and I'd like to encourage you to share back. Please check out Blendix, and make liberal use of the information you find under the "Contact" link at the bottom of every page. Let me know what you think, especially if you're a programmer and you've got some ideas for hacking on the code. This will be especially useful as get into the initial phase of pushing the core out to the community. Also, we really want to make sure the experience is as bug-free as possible, so let us know about any problems you have.
|
|
|
|
|
|
|
|
|
|
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
glyf's journal
Previous
