[Python-Dev] [RELEASED] Python 2.7 alpha 2
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:
__metaclass__ = Meta
and in Python 3 it's:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 835 bytes
Desc: not available
More information about the Python-Dev