[Python-Dev] [RELEASED] Python 2.7 alpha 2 (original) (raw)

Barry Warsaw barry at python.org
Tue Jan 12 01:11:28 CET 2010

On Jan 11, 2010, at 10:42 PM, Martin v. Löwis wrote:

Wrt. the distribute feature you've noticed: Python 3.0 already supports that in distutils. So from day one of Python 3.x, you could have used that approach for porting Python code. I had been promoting it ever since, but it's taking up only slowly, partially because it has competition in the approaches "burn the bridges" (i.e. convert to 3.x once, and then have two code bases, or abandon 2.x), and "avoid 2to3" (i.e. try to write code that works in both 2.x and 3.x unmodified).

Interesting. The only reason I never used it before is because I didn't know about it. Am I alone?

Maybe I'm projecting my own preferences, but it seems to me that supporting both Python 2 and 3 from the same code base would be a very powerful way to enable a large amount of existing code to support Python 3. I'm certainly going to do this from now on with all the libraries I maintain. I don't have any cycles to write code twice and I can't abandon Python 2 yet. I'm skeptical that code can work unmodified in both 2 and 3 without 2to3.

As an example, the one library I've already ported used a metaclass. I don't see any way to specify that the metaclass should be used in a portable way. In Python 2.6 it's:

class Foo: metaclass = Meta

and in Python 3 it's:

class Foo(metaclass=Meta):

2to3 made that pain go away.

I've done a fair bit of 3.x porting, and I'm firmly convinced that 2.x can do nothing:

a) telling people that they have to move to 2.6 first actually hurts migration, instead of helping, because it implies to them that they have to drop old versions (e.g. 2.3.) - just because they had always dropped old versions before supporting new ones.

Is it just an implication, or is it reality? I have yet to try to support older versions of Python and also support Python 3. (The one package I've done this with so far only supports Python 2.6.)

b) IMO, people also don't gain much by first migrating to 2.6. In principle, it gives them the opportunity to get py3k warnings. However, I haven't heard a single positive report where these warnings have actually helped people in porting. Yours is the first report saying that you followed the official guideline, but you didn't state whether doing so actually helped (or whether you just ported to 2.6 because the guideline told you to).

Python 2.6 has other useful features, which I want to take advantage of, so getting py3k warnings is a bonus. Running 'python2.6 -3 setup.py test' over my code did in fact help clean up a couple of problems. Seems like a good first step when considering Python 3 support to me.

c) whatever 2.7 does (except perhaps for the warnings), it won't be useful to applications, because they couldn't use it, anyway: they need to support 2.4 and 2.5, and it won't have any of the gimmicks people come up with for 2.7. Adding gimmicks to 2.7 might actually hurt porting: people may have to special-case 2.7 because their work-arounds for older versions may break in 2.7 (e.g. testing whether a name is not defined, when it becomes defined in 2.7), plus it gives them an incentive to not port yet until they can drop support for anything before 2.7.

Inherently, 2.8 can't improve on that.

I'm not so sure. Yes, as a package maintainer there are older versions to think about, but time moves on for everyone (hopefully :). By the time 2.8 is released, what will be the minimum version of Python provided by most OS vendors (where the majority of Python users probably get their 'python')? I guess some people will have to support everything from Python 2.3 to 2.8 but you're talking supporting something like a spread of 7 years of Python versions. What other platform do you support for 7 years? Even Ubuntu long term support (LTS) releases only live for 5 years and even then, newer Pythons are often back ported. Or if not, then who cares? You're not going to use a newer version of a library on an LTS anyway.

I'm not necessarily saying that justifies a 2.8 release. I'm just asking how we can make it easier for people to port to Python 3. The automatic 2to3 has already made it easier for me to port one library to Python 3 because I barely had to even think about it. Maybe that's enough.

-Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20100111/840169eb/attachment-0007.pgp>

More information about the Python-Dev mailing list