Readers should note that this release has significant backwards incompatibilities with the 2.X series, both at the language level and also in the C APIs available to extension module authors. These have been introduced by design, with the goal of improving the language in the long term, but this situation has implications for production use.I hope that clarifies things, but I would welcome further ideas to refine this text and make it more helpful. One of the primary reasons for using 3.0 is to get a migration strategy ready. But 3.0 is undoubtedly not for everyone, at least not just yet.
Furthermore it is likely that there will be a considerable delay before some authors of Python packages and extension modules start to provide 3.0-compatible releases. There are significant hurdles to be overcome in migrating extension modules from Python 2 to Python 3.
For these reasons you are NOT recommended to rely on Python 3.0 as your main production Python implementation until you know that all supporting code is available in compatible forms. While every care has been taken in the production of the Python 3.0 release, and the release team feels that the system is of a quality comparable with the recently-released Python 2.6, the latter system is currently the recommended version for production use.
"Any sufficiently advanced technology is indistinguishable from magic" -- Arthur C Clarke
Musings from the technological frontier
November 13, 2008
Don't Use Python 3.0? Really?
It's difficult to say "don't use Python 3.0" without being rude to the developers, as the code seems to be of very high quality. Now that Python 3.0 is almost here (release candidate 2 is a week old as I write) we should encourage people to use it, but only under well-defined circumstances. Here is some text I put together for inclusion in the release notes, to give people guidance about when and why it is and isn't appropriate to use 3.0. I would welcome further ideas to refine this text.
Subscribe to:
Post Comments (Atom)
6 comments:
Fabio Zadrozny (Mr. Pydev - the Python Eclipse Plug-In) is feeling the pain.
http://pydev.blogspot.com/2008/11/pydev-python-30.html
When are we going to get 3toAny2 tools? Python 3 has nice canonical ways to do i18n and byte manipulation, so eventually it will be the preferred way to code. But we will need 3toAny2 tools (because supporting only 2.6 & 2.7 is not realistic)
(Did you know Top-Down parsing rawks? http://effbot.org/zone/simple-top-down-parsing.htm If I begin writing my own 3toAny2 tools, it will be using this technique. I recommend it to anyone who prefers good-ol' coding to playing with grammars and parsers.)
On the flip side some of us authors of packages did the Python 3 port months ago and are just waiting for the final release before we can publish package binaries for the most common operating system out there (Windows) :-)
How about a challenge to folks posting code samples, snippets and such on-line: either write it with Python 3 in mind, run 2to3 on it, or point out in posts where issues lurk.
By the way: docutils and Pygments get my vote as two packages that most need porting to 3.0; writing tools ought to be high on the priority list.
@manuelg: I don't know of anyone working on backporting tools; they would be useful, but someone would need to put a lot of work in.
@Anonymous: Glad you are ready!
@Michael Watkins: a good idea. This could be something a lot of people would be interested in.
Don't tell people not to use 3.0 for production use. 3.0 will be released in a production ready state. Instead emphasize that support by external packages is beyond your control so users should ensure that any external modules they need are available under 3.0. After all, Python 3.0 comes with batteries included too.
- Paddy.
Generally it's a bad idea to rely on a x.0 version of any software. Python 3.0 hasn't yet been banged on much outside the devs.
Post a Comment