Log in

No account? Create an account
entries friends calendar profile Scribbles in the Dark Previous Previous Next Next
There is a flash of light! Your PYTHON has evolved into PSYDUCK! - Please Visit http://glyph.twistedmatrix.com/ - This Blog Is Closed.
Sorry about the ads, I can't turn them off.
There is a flash of light! Your PYTHON has evolved into PSYDUCK!
I guess if you don't read any other python-related blogs (or news, or mailing lists, for that matter) you might not already know that the first alpha of Python 3.0 has been released.

A sample of the release notes:
  • There are a few memory leaks
  • SSL support is disabled
  • Platform support is reduced
  • There may be additional issues on 64-bit architectures
  • There are still some open issues on Windows
  • Some new features are very fresh, and probably contain bugs
  • IDLE still has some open issues
In other words, this is not a product for general consumption, and is not labeled as such.  Do not use it expecting to be able to get real work done with it.  This release is to help the Python development team find bugs and get feedback from the community.

I've already blogged about my inability to get excited about Python 3.0.  Now that it's begun to arrive, I can more clearly see the scope of the work required to get in sync with it, and the new features that it is actually going to encompass.  It's a staggering amount of work.

Jean-Paul Calderone has prepared a preliminary run of the 2to3 tool over the Twisted codebase.  This includes a 820 kilobyte diff, which took 12 minutes to produce (on a fairly fast, modern piece of hardware).  However, this is not even a complete run, because the 2to3 tool cannot even parse two of the files in the repository, despite the fact that they are all valid python.  Many of the transformations (especially in the area of the unicode/str conversion) are almost certainly going to drastically change the semantics our test suite, if not break it - although enough of Twisted's dependencies are missing on 3.0 that I haven't even had an opportunity to try.

I still hold out hope that the 3.0 branch will gradually be abandoned, as these changes are rolled back into older versions (2.6+) of Python and gradually phased in, with their deprecated alternatives being gradually phased out.  Right now, though, the plan is to continue parallel development in the 2.x series until 3.0 is ready to "take over", although I'm not sure how that determination will be made.

While I wish I could be more excited about something in the 3.0 roadmap, it worries me that some of the excitement I see from others is enthusiasm for the idea of using it as an excuse to break their own users' software too.  If you've written a library for Python, please consider that its users are going to be having a hard enough time upgrading from python 2.x to 3.x; you should really try to provide the smoothest migration path from here to there, and keep your APIs as compatible as possible.

Although I'd like to say something nice and congratulatory, the thought of spending a year just pushing little piles of syntax into other little piles of syntax, even with the help of a tool like a hypothetically-much-more-advanced 2to3, is honestly just depressing.  I'd have to get Twisted (and Axiom and Nevow and Mantissa and Quotient and a handful of proprietary projects that I work on) to work on Python 3.0 before I can use it.  If I'm going to work on Twisted, I have a lot of other things I'd rather be doing.  So my plan, for the moment, is to ignore Python 3.0 as long as I possibly can.

But hey, that's what the magic of open source is supposed to be about, right?  Do you like Python 3.0?  Do you want to see Twisted (and the various Divmod projects) eventually support it?  A fairly substantial portion of the diff in question is a litany of non-controversial stylistic changes to update old, and sometimes creaky parts of the codebase.  For example, there are a bunch of usages of the 'print' statement that need to be transformed; you might consider submitting a patch which simply removes all usages of "print", since we probably shouldn't be using that syntax anyway.  That will reduce the size of the changes that we need to consider, generate, and apply in order to be 3.0 compliant. and probably improve the code's cleanliness quite a bit.  Once those parts are applied, and thereby removed from the output of 2to3, we can have a better view of what work is actually necessary to support 2.x and 3.0 versions simultaneously from the same codebase.

Of course, comprehensive test coverage is something else frequently brought up when talking about the 2-to-3 migration.  Any patches which increase or improve our test coverage will alway be greatly appreciated regardless of any migration issues.

The one prospect that appeals to me is that, if 3.0 successfully adheres to the vague promise of breaking backwards compatibility "just this once", Python may move towards being a real platform instead of simply a tool that you run on another platform.  Of course, backwards incompatible changes can be a bit like potato chips - "you can't eat just one" - but I trust that the Python team can stick to it if they see the value in it and have made the incompatible changes they think are significant and necessary.

A few days ago I ran Neverwinter Nights on my Ubuntu (feisty) machine and was pleased to discover that despite the fact that there are new versions of SDL, X11, the Linux kernel, GNOME, ALSA, and a dozen other dependencies (all of which are dynamically bound) since five years ago when it was written, it still runs beautifully, with no configuration or re-installation on my part.  Getting that kind of reliability from Python, and being able to provide it for Twisted, would be worth a fair amount of time spent overhauling syntax.
5 comments or Leave a comment
smitty1e From: smitty1e Date: September 1st, 2007 10:37 am (UTC) (Link)

I think that one of the goals

...was to write a translator that would mostly do the port for you.
The absolute killer right now, on the release page, is the ~30% performance penalty cited.
While all the polishing of the language is swell for pedantic reasons, no one wants to see performance suffer. You figure they'll buff that up over the next year.
From: mesozoic Date: September 3rd, 2007 06:36 am (UTC) (Link)

What is a platform?

How do you see the Python 3.0 release offering the potential of being a "real platform"? What's the substantive difference between application deployment in 2.x and in 3.0 that could qualify that distinction?
glyf From: glyf Date: September 8th, 2007 09:49 pm (UTC) (Link)

Re: What is a platform?

The words "library", "engine", "toolkit", and "framework" all imply to me that while the code may be usable, it still might not be stable enough to depend on in your installed environment. You can see this in the way that commercial software treats its environment: they will distribute everything, right down to the C runtime that the application uses, along with their application.

The word "platform" means some code that you don't or can't distribute with your application.

Some things become platforms without stability due to the inability to share resources. For example, X11 is a platform regardless of some of the instability and experimental stuff present in the Render and Composite extensions, since you only have one graphics card. In other cases the "resource" is a license: if you're writing a Photoshop plugin, Photoshop is your platform.

The stability that comes along with a more or less permanent commitment to a really stable API can also make you a "platform". UNIX's libc, for example, pretty much just works; you never have to distribute your own "strlen" or "creat" implementation along with your application. Even "gets", a horror which has been deprecated for decades now, will still work (screaming at you the whole time) if you have some really old code which uses it.

Platforms do have one key advantage; they can specify ways that code distributed by different "vendors" can communicate with each other. For example, the UNIX platform has the ability to locate other code by looking around the filesystem and using dlopen(). Photoshop plugins can publish metadata about themselves that photoshop (and other plugins) can read. Python right now has a lot of useful tools in this area, and systems like twisted.plugin and setuptools show promise of some interesting capabilities that Python-as-a-platform might develop: but if those APIs change, then you've got a new platform each time, and authors who want their applications to "just work" for end users will distribute the entire environment with their application, making it a closed system.
From: zingo454 Date: November 24th, 2007 06:56 pm (UTC) (Link)
Does Python 3.0 will break backwards compatibility with Python 2.x ?

About Pregnancy
From: elfidel Date: December 20th, 2007 05:58 pm (UTC) (Link)

Great website! Bookmarked! I am impressed at your work!

5 comments or Leave a comment