myths about python 3

[alex23]

Actually, Unladen Swallow is now targeted at 3.1; its developers have
conservatively proposed its integration in CPython 3.3. I would not be
completely shocked if it happens in 3.2.

Why do I feel like there's less of an onus on Unladen Swallow to
_actually prove itself in substantial real world usage_ before
integration into CPython than there is on even the smallest of modules
for inclusion in the standard library?

Are we really expected to just ditch everything we know about
CPython's performance characteristics just for some questionable and
possibly uneven gains?

I've been a big supporter of Py3 from the beginning, but this repeated
claim of US becoming the mainline interpreter for 3.x pretty much
kills dead a lot of my interest. What am I not seeing amidst the high
memory usage and variable performance results of US's _custom-made_
benchmarks? Doesn't that fact alone worry anyone else? Or that LLVM is
listed as only having "partial support" with non-Cygwin x86 Windows?

Yes, I'd _love_ Python to be faster, who wouldn't? But I'm not seeing
the evidence here to support the almost unbridled eagerness that's
being demonstrated.

 

[Steven D'Aprano]

That is heresy. The direction was up, not down.

SPLITTER!!!

 

[Carl Banks]

Why do I feel like there's less of an onus on Unladen Swallow to
_actually prove itself in substantial real world usage_ before
integration into CPython than there is on even the smallest of modules
for inclusion in the standard library?

I don't sense that. I get a sense that there's a lot of people
licking their chops because it's sponsored by Google and everything
Google touches turns to gold, but that's just nameless plebians. I
trust the developers not to be easily convinced. If GvR allows this
into CPython without something like a typical 4x speed increase I'll
eat my hat.

Carl Banks

 

[Neil Hodgson]

Carl Banks:

There is also no hope someone will fork Python 2.x and continue it in
perpetuity. Well, someone might try to fork it, but they won't be
able to call it Python.

Over time there may be more desire from those unable or unwilling to
upgrade to 3.x to work on improvements to 2.x, perhaps leading to a
version 2.8. One of the benefits of open source is that you are not
trapped into following vendor decisions like Microsoft abandoning
classic VB in favour of VB.NET.

It would be unreasonable for the core developers to try to block
this. Refusing use of the Python trademark for a version that was
reasonably compatible in both directions would be particularly petty.

Neil

 

[Steve Holden]

Myths about Python 3:

1. Python 3 is supported by major Linux distributions.

FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

Why would a "major Linux distribution" want to saddle themselves with
such a new technology so erly in its lifetime?

2. Python 3 is supported by multiple Python implementations.

FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow,
PyPy, and Jython have all stayed with 2.x versions of Python.

Your selective information here is particularly partial to your case. I
have spoken with developers from IronPython and Jython, and both teams
are committed to eventual support of 3.x.

3. Python 3 is supported by most 3rd party Python packages.

FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

I would argue it's up to Python to support those facilities rather than
the other way round.

Arguably, Python 3 has been rejected by the market. Instead, there's
now Python 2.6, Python 2.7, and Python 2.8. Python 3 has turned into
a debacle like Perl 6, now 10 years old.

That's the reality, Python 3 fanboys.

Kindly confine your debate to the facts and keep the snide remarks to
yourself. Like it or not Python 3 is the future, and unladen swallow's
recent announcement that they would target only Python 3 represented a
ground-breaking advance for the language.

Happily my Python 2.x interpreters all continue to work just as they
have since they were installed. If you have to stretch as far as Perl 6
for an analogy then you have clearly stretched a little too far. The
situations are not even closely comparable, and I defy you to argue
otherwise.

regards
Steve

 

[Steve Holden]

Myths about Python 3:

1. Python 3 is supported by major Linux distributions.

FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

Why would a "major Linux distribution" want to saddle themselves with
such a new technology so erly in its lifetime?

2. Python 3 is supported by multiple Python implementations.

FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow,
PyPy, and Jython have all stayed with 2.x versions of Python.

Your selective information here is particularly partial to your case. I
have spoken with developers from IronPython and Jython, and both teams
are committed to eventual support of 3.x.

3. Python 3 is supported by most 3rd party Python packages.

FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

I would argue it's up to Python to support those facilities rather than
the other way round.

Arguably, Python 3 has been rejected by the market. Instead, there's
now Python 2.6, Python 2.7, and Python 2.8. Python 3 has turned into
a debacle like Perl 6, now 10 years old.

That's the reality, Python 3 fanboys.

Kindly confine your debate to the facts and keep the snide remarks to
yourself. Like it or not Python 3 is the future, and unladen swallow's
recent announcement that they would target only Python 3 represented a
ground-breaking advance for the language.

Happily my Python 2.x interpreters all continue to work just as they
have since they were installed. If you have to stretch as far as Perl 6
for an analogy then you have clearly stretched a little too far. The
situations are not even closely comparable, and I defy you to argue
otherwise.

regards
Steve

 

[Paul Rubin]

Kindly confine your debate to the facts and keep the snide remarks to
yourself. Like it or not Python 3 is the future, and unladen swallow's
recent announcement that they would target only Python 3 represented a
ground-breaking advance for the language.

My take on things is that doing unladen swallow really "right" will
require yet more incompatible changes; i.e., the result will either
still leave quite a bit of performance on the table, or else it won't be
compatible with the current specification of Python 3 and they'll
presumably have to call it Python 4. And if Python 4 is as good as I
believe it could possibly be, then it might get wide acceptance before
Python 3 really has all that much uptake. If I have to accept
incompatibility anyway, and Python 4 gives huge improvements while
Python 3's improvements are tiny or moderate, why not skip over Python 3?

 

[Terry Reedy]

This statement was to counter the 'myth' that US was only targeted at
2.x when the current situation is quite the opposite.

I was initially rather dubious about the idea. I based the above
on the team's acceptance of and response to reasonable requirements.
In particular, several people said that the speed/space traceoff
should be optional, and that compilation 'without llvm' should really
be without, not just with llvm present but disabled. Instead of arguing,
Colin went ahead and patched the build process to make it be this way.

Why do I feel like there's less of an onus on Unladen Swallow to
_actually prove itself in substantial real world usage_ before
integration into CPython than there is on even the smallest of modules
for inclusion in the standard library?

I have no idea. It will have to improve its speedup more before
adoption. I will not be surprised if that happens.

Are we really expected to just ditch everything we know about
CPython's performance characteristics just for some questionable and
possibly uneven gains?

I've been a big supporter of Py3 from the beginning, but this repeated
claim of US becoming the mainline interpreter for 3.x

US is not a new or separate interpreter. It will be an optional jit
replacement for one component of CPython, the eval loop. All the code
for builting functions, types, and modules will be untouched, as will
their big O performance characteristics.

pretty much kills dead a lot of my interest.

If you can still have a binary free of the traceoff, why would you care?

> What am I not seeing amidst the high
memory usage and variable performance results of US's _custom-made_
benchmarks? Doesn't that fact alone worry anyone else? Or that LLVM is
listed as only having "partial support" with non-Cygwin x86 Windows?

They claim they have pretty well fixed that. They know that complete
Windows support, including 64 bit versions, is a necessity.

Terry Jan Reedy

 

[Stefan Behnel]

Benjamin Kaplan, 27.01.2010 22:25:

When Python 2.6 came out, Jython was still on 2.2. The difference
between 2.2 and 2.6 is almost as big of a difference as between 2.6
and 3.0.

From an implementors point of view, it's actually quite the opposite. Most
syntax features of Python 3 can be easily implemented on top of an existing
Py2 Implementation (we have most of them in Cython already, and I really
found them fun to write), and the shifting-around in the standard library
can hardly be called non-trivial. All the hard work that went into the
design of CPython 3.x (and into its test suite) now makes it easy to just
steal from what's there already.

The amount of work that the Jython project put into catching up from 2.1 to
2.5/6 (new style classes! generators!) is really humongous compared to the
adaptations that an implementation needs to do to support Python 3 code. I
have great respect for the Jython project for what they achieved in the
last couple of years. (I also have great respect for the IronPython project
for fighting the One Microsoft Way into opening up, but that's a different
kind of business.)

If there was enough interest from the respective core developers, I
wouldn't be surprised if we had more than one 'mostly compatible'
alternative Python 3 implementation in a couple of months. But it's the
obvious vicious circle business. As long as there aren't enough important
users of Py3, alternative implementations won't have enough incentives to
refocus their scarce developer time. Going for 2.6/7 first means that most
of the Py3 work gets done anyway, so it'll be even easier then. That makes
2.6->2.7->3.2/3 the most natural implementation path. (And that, again,
makes it a *really* good decision that 2.7 will be the last 2.x release line.)

Give the package maintainers time to update. There were some pretty
big changes to the C API. Most of the major 3rd party packages like
numpy and MySQLdb have already commited to having a Python 3 version.
They just haven't gotten them out yet.

I second that. NumPy has already announced that they'll rewrite some of
their code in Cython to make it more maintainable and portable (and to
simplify the port to Py3, I guess). Other projects will equally well find
their ways to get their code ready. It's just a matter of time. I think
there's enough pressure on the maintainers by now (both from users and from
personal pride) to consider their packages tainted if they aren't portable
enough to run on all major (C)Python versions (and Py3.1 certainly is one
of them), even if they don't use them themselves. That appears to be an
impressively good incentive.

Stefan

 

[Stefan Behnel]

Ben Finney, 27.01.2010 22:50:

Only if by “modern†you mean “not released yetâ€.

The latest stable Debian (Debian 5.0, Lenny) has only Python 2.4 and
Python 2.5. It does not have Python 2.6 at all, and until this month
Python 2.6 was not even in the in-development suite of Debian.

'Stable Debian' has a long tradition of being late and outdated on arrival.
That doesn't mean you can't use existing Debian packages on it. And there
certainly are .deb packages available for Py3.1.1 - Ubuntu uses them, and
other Debian based distributions do, too.

And Ubuntu Karmic definitely uses Py2.6 as 'python'.

Stefan

 

[Paul Rubin]

The amount of work that the Jython project put into catching up from 2.1 to
2.5/6 (new style classes! generators!) is really humongous compared to the
adaptations that an implementation needs to do to support Python 3 code.

I wonder whether Jython could borrow code from Clojure for some of this
stuff, to save a little work. Cross-fertilization between free software
projects is usually a good thing.

 

[Aahz]

I believe that, with the possible exception of the change from byte
strings to unicode strings, virtually *all* the hoo-har over Python 3 is
simply due to the tactical mistake of Guido and the Python Dev team of
*calling* Python 3 a backward incompatible release. Python has had
previous major changes in the past (e.g. 1.5 to 2.0 and 2.1 to 2.2) and
hardly anyone made a complaint.

But as Steven points out, the difference from 2.2 to 2.6 is roughly the
same as 2.6 to 3.1. Python has never before had such a large difference
from one release to the next, and I think few people try to support
serious apps on the full range from 2.2 to 2.6. Moreover, the task of
using a single codebase without 2to3 is much easier in 1.4 through 2.6.

Admittedly, it wouldn't be much fun to write 1.4 code these days without
all the neat features that have been added, but you can't argue that it's
hard.

 

[Aahz]

Carl Banks:

Over time there may be more desire from those unable or unwilling to
upgrade to 3.x to work on improvements to 2.x, perhaps leading to a
version 2.8. One of the benefits of open source is that you are not
trapped into following vendor decisions like Microsoft abandoning
classic VB in favour of VB.NET.

It would be unreasonable for the core developers to try to block
this. Refusing use of the Python trademark for a version that was
reasonably compatible in both directions would be particularly petty.

Agreed, and as a PSF member, I'd certainly be opposed to anyone trying to
prevent the release of Python 2.8, and I would actively favor providing
PSF and python.org resources to them. OTOH, I would also be likely to
push anyone working on Python 2.8 to come up with a solid release plan
first.

 

[Dino Viehland]

syntax features of Python 3 can be easily implemented on top of an existing
Py2 Implementation (we have most of them in Cython already, and I really
found them fun to write), and the shifting-around in the standard library
can hardly be called non-trivial. All the hard work that went into the
design of CPython 3.x (and into its test suite) now makes it easy to just
steal from what's there already.

The amount of work that the Jython project put into catching up from 2.1 to
2.5/6 (new style classes! generators!) is really humongous compared to the
adaptations that an implementation needs to do to support Python 3 code. I
have great respect for the Jython project for what they achieved in the
last couple of years. (I also have great respect for the IronPython project
for fighting the One Microsoft Way into opening up, but that's a different
kind of business.)

If there was enough interest from the respective core developers, I
wouldn't be surprised if we had more than one 'mostly compatible'
alternative Python 3 implementation in a couple of months. But it's the
obvious vicious circle business. As long as there aren't enough important
users of Py3, alternative implementations won't have enough incentives to
refocus their scarce developer time. Going for 2.6/7 first means that most
of the Py3 work gets done anyway, so it'll be even easier then. That makes
2.6->2.7->3.2/3 the most natural implementation path. (And that, again,
makes it a *really* good decision that 2.7 will be the last 2.x release line.)

I just want to echo this as I completely agree. Last time I went through the
list it looked like there were around 10 major new features (some of them even
not so major) that we needed to implement to bring IronPython up to the 3.0
level. It shouldn't be too time consuming, and it greatly improves our
compatibility by finally having the same string types, but our users don't
yet want us to stop supporting 2.x.

 

[Antoine Pitrou]

Le Thu, 28 Jan 2010 00:19:24 +0000, Steven D'Aprano a écrit :

4. Python 3 will make you irresistible to women.

FALSE - Python 3 coders are no more likely to get a date than any
other programmer.

They spend less time coding, so they /can/ get more "dates" (what a
strange English word)
Those dates don't have to be with women of course.

 

[Antoine Pitrou]

Le Wed, 27 Jan 2010 17:36:29 -0800, alex23 a écrit :

I've been a big supporter of Py3 from the beginning, but this repeated
claim of US becoming the mainline interpreter for 3.x pretty much kills
dead a lot of my interest.

As long as the U-S JIT can be disabled at compile-time (and also at
runtime), I don't think there's much of a contention actually.
The other changes probably aren't controversial, although I haven't
looked at them.


Antoine.

 

[Ethan Furman]

4. Python 3 will make you irresistible to women.

FALSE

What?!? Drat!!! Guess I'll have to learn Lisp...

~Ethan~

 

[Carl Banks]

Agreed, and as a PSF member, I'd certainly be opposed to anyone trying to
prevent the release of Python 2.8, and I would actively favor providing
PSF and python.org resources to them.  OTOH, I would also be likely to
push anyone working on Python 2.8 to come up with a solid release plan
first.

Well, I'd consider that an official release. Note that I didn't claim
there was no hope PSF wouldn't change it's mind on 2.8. All I saying
is that if PSF decides to shut down 2.x there's no hope of a rogue
Python 2.x series replacing Python 3.x.

Regardless of how magnaminous the people of PSF are, the unfortunate
reality is that trademark owners are forced by the law to be
"particularly petty". PSF's IP lawyer will advise not to allow
unsanctioned fork of Python 2.7 to call itself Python 2.8.


Carl Banks

 

[Steve Holden]

Well, I'd consider that an official release. Note that I didn't claim
there was no hope PSF wouldn't change it's mind on 2.8. All I saying
is that if PSF decides to shut down 2.x there's no hope of a rogue
Python 2.x series replacing Python 3.x.

Regardless of how magnaminous the people of PSF are, the unfortunate
reality is that trademark owners are forced by the law to be
"particularly petty". PSF's IP lawyer will advise not to allow
unsanctioned fork of Python 2.7 to call itself Python 2.8.

But if it were sanctioned ... ? We *are* pretty magnanimous ;-)

regards
Steve

 

[Steve Holden]

Well, I'd consider that an official release. Note that I didn't claim
there was no hope PSF wouldn't change it's mind on 2.8. All I saying
is that if PSF decides to shut down 2.x there's no hope of a rogue
Python 2.x series replacing Python 3.x.

Regardless of how magnaminous the people of PSF are, the unfortunate
reality is that trademark owners are forced by the law to be
"particularly petty". PSF's IP lawyer will advise not to allow
unsanctioned fork of Python 2.7 to call itself Python 2.8.

But if it were sanctioned ... ? We *are* pretty magnanimous ;-)

regards
Steve