On 01:12 am, email@example.com wrote:
On Friday 12 January 2007 06:09, James Y Knight wrote:
On Jan 10, 2007, at 6:46 PM, Benji York wrote:
Paul Moore wrote:
How many other projects/packages anticipate *not* migrating to Py3K, I wonder?
I certainly can't speak for the project as a whole, but I anticipate a fair bit of work to port Zope 3 (100+ KLOC) to Python 3.0.
I (another Twisted developer, among other hats I wear) am also very worried about the Python 3.0 transition.
I'm plan to try and make the transition as painless as possible. A goal I have is to try and make it possible to write code that works in both 2.6 and 3.0. Obviously 2.6 will be backwards-compatible with previous versions, but I'd like to see it get either a command line option or a from __future__ statement to enable compatibility with 3.0-isms, like the dict.items change.
This is all very encouraging.
Please stick with a __future__ statement if at all possible though. The biggest challenge in migration is to reduce the impact so that it can be done partially in a real system.
If you have a module X wants to be "3.0 safe" which imports a module Y from a different developer that is not, command line options for compatibility might not help at all. A __future__ statment in X but not in Y, though, would allow for a smooth transition.
I can see how that would be tricky for things like dictionary methods, but it does seem doable. For example, have a has_key descriptor which can raise an AttributeError if the globals() of the calling stack frame has been marked in some way.
Basically: my plea is: please don't remove the old way of doing things in Py 3.0 at the same time as you add the new way of doing things.
If there was a way to make 2.6 as compatible as possible with 3.0, would this make life less painful? Obviously there'd have to be breakages in a backwards direction, but I'd hope it would make it easier to go forward. Some things should also be OK to backport to 2.6 - for instance, I can't see an obvious reason why 2.6 can't support "except FooError as oopsie" as an alternate spelling of "except FooError, oopsie".
You happen to have hit my favorite hot-button 3.0 issue right there :). I don't care about backticks but sometimes I _do_ have to catch exceptions.
Similarly, where the stdlib has been shuffled around, there should be shims in 2.6 that allow people to work with the new names.
This part I wouldn't even mind having to write myself. It would certainly be good to have somewhere more official though.
I don't think waiting for 2.7 to make the compatibility work is a workable approach - we're something like 2.5-3 years away from a 2.7 release, and (optimistically) 12-18 months from a 3.0 final. That leaves a window of 1.5-2 years where we are missing an important tool for people.
It would be nice if the versioning would actually happen in order.
 Unless of course there's a perfect automated conversion script that can generate the 3.X compatible source code from the 2.X compatible source code.
I doubt that the 2to3 script will be perfect, but hopefully it can get most things. I can't see it easily fixing up things like
check = mydict.has_key ... if check(foo):
Currently a common idiom, by the way, used throughout the lower levels of Twisted.
This is why I also want to add Py3kDeprecationWarning to 2.6.
On that note, I'd like to see changes like the mass-change to the stdlib in the 3.0 branch that changed raise A, B into raise A(B) applied to the trunk. This makes it much easier to apply patches to both the 3.0 branch and the trunk. Similar changes should be applied to remove, for instance, use of <> and dict.has_key from the stdlib. Simply put, I'd like the stdlib between 2 and 3 to be as similar as possible.
It would be nice if the stdlib could be used as a case study - if the 3 stdlib tests can pass on some version of 2 (or vice versa) that should be a minimum bar for application portability.
Maybe a better way to handle the similarity is that the reorganized stdlib should simply be available as a separate piece of code on 2.x? That would allow 2.x to use any new features added and distinguish between code which had been moved to use new stdlib APIs and that which hadn't.