myths about python 3
in [Python]
|
Prev: Ad hoc lists vs ad hoc tuples
Next: Python and Ruby
From: Stefan Behnel on 28 Jan 2010 03:00 Benjamin Kaplan, 27.01.2010 22:25: > On Wed, Jan 27, 2010 at 3:56 PM, John Nagle <nagle(a)animats.com> wrote: >> 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. >> > 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.) >> 3. Python 3 is supported by most 3rd party Python packages. >> >> FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc. >> >> 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. > > 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
From: Stefan Behnel on 28 Jan 2010 03:11 Ben Finney, 27.01.2010 22:50: > Christian Heimes writes: > >> John Nagle wrote: >>> 1. Python 3 is supported by major Linux distributions. >>> >>> FALSE - most distros are shipping with Python 2.4, or 2.5 at best. >> You are wrong. Modern versions of Debian / Ubuntu are using Python >> 2.6. > > 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
From: Paul Rubin on 28 Jan 2010 03:40 Stefan Behnel <stefan_ml(a)behnel.de> writes: > 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.
From: Aahz on 28 Jan 2010 11:06 In article <pan.2010.01.28.00.35.41(a)REMOVE.THIS.cybersource.com.au>, Steven D'Aprano <steven(a)REMOVE.THIS.cybersource.com.au> wrote: >On Wed, 27 Jan 2010 16:25:46 -0500, Benjamin Kaplan wrote: >> >> 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. In that time, you had the introduction of the boolean type, >> generators, list comprehensions, the addition of the "yield" and "with" >> keywords, universal newline support, and decorators in addition to the >> large number of changes to the standard library such as the introduction >> of the subprocess module. > >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 (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity
From: Aahz on 28 Jan 2010 11:10
In article <Zt68n.3893$pv.1546(a)news-server.bigpond.net.au>, Neil Hodgson <nyamatongwe+thunder(a)gmail.com> wrote: >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. 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. -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ import antigravity |