myths about python 3

10 views
Skip to first unread message

Daniel Fetchinson

unread,
Jan 27, 2010, 5:32:08 AM1/27/10
to Python
Hi folks,

I was going to write this post for a while because all sorts of myths
periodically come up on this list about python 3. I don't think the
posters mean to spread false information on purpose, they simply are
not aware of the facts.

My list is surely incomplete, please feel free to post your favorite
misconception about python 3 that people periodically state, claim or
ask about.

1. Print statement/function creates incompatibility between 2.x and 3.x!

Certainly false or misleading, if one uses 2.6 and 3.x the
incompatibility is not there. Print as a function works in 2.6:

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print( 'hello' )
hello
>>> print 'hello'
hello
>>>


2. Integer division creates incompatibility between 2.x and 3.x!

Again false or misleading, because one can get the 3.x behavior with 2.6:

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 6/5
1
>>> from __future__ import division
>>> 6/5
1.2


Please feel free to post your favorite false or misleading claim about python 3!

Cheers,
Daniel


--
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Stefan Behnel

unread,
Jan 27, 2010, 5:40:27 AM1/27/10
to
Daniel Fetchinson, 27.01.2010 11:32:

> 1. Print statement/function creates incompatibility between 2.x and 3.x!
>
> Certainly false or misleading, if one uses 2.6 and 3.x the
> incompatibility is not there. Print as a function works in 2.6:
>
> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> print( 'hello' )
> hello
> >>> print 'hello'
> hello

This is actually misleading by itself, as the first statement is not a
function call in Py2:

Python 2.6.4 (r264:75706, Dec 7 2009, 18:43:55)
[GCC 4.4.1] on linux2


Type "help", "copyright", "credits" or "license" for more information.

>>> print(1,2)
(1, 2)

It can, however, be made a function call through a future import in 2.6:

>>> from __future__ import print_function
>>> print(1,2)
1 2

Stefan

Andre Engels

unread,
Jan 27, 2010, 5:45:48 AM1/27/10
to Daniel Fetchinson, Python
On Wed, Jan 27, 2010 at 11:32 AM, Daniel Fetchinson
<fetch...@googlemail.com> wrote:
> Hi folks,
>
> I was going to write this post for a while because all sorts of myths
> periodically come up on this list about python 3. I don't think the
> posters mean to spread false information on purpose, they simply are
> not aware of the facts.
>
> My list is surely incomplete, please feel free to post your favorite
> misconception about python 3 that people periodically state, claim or
> ask about.
>
> 1. Print statement/function creates incompatibility between 2.x and 3.x!
>
> Certainly false or misleading, if one uses 2.6 and 3.x the
> incompatibility is not there. Print as a function works in 2.6:
>
> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> print( 'hello' )
> hello
>>>> print 'hello'
> hello
>>>>
>
>
> 2. Integer division creates incompatibility between 2.x and 3.x!
>
> Again false or misleading, because one can get the 3.x behavior with 2.6:

>
> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> 6/5
> 1
>>>> from __future__ import division
>>>> 6/5
> 1.2
>
>
> Please feel free to post your favorite false or misleading claim about python 3!

Well, I see two false or misleading claims just above - namely that
the two claims above are false or misleading. They tell just half of
the story, and that half is indeed easy. A Python 3 program can be
unchanged (in the case of print) or with only trivial modifications
(in the case of integer division) be made to run on Python 2.6. The
other way around this is _not_ the case. To say that two things are
compatible if one can be used for the other, but the other not for the
first, is false or misleading.


--
André Engels, andre...@gmail.com

Daniel Fetchinson

unread,
Jan 27, 2010, 9:22:39 AM1/27/10
to Python

Okay, so we agree that as long as print and integer division is
concerned, a program can easily be written that runs on both 2.6 and
3.x.

My statements are exactly this, so I don't understand why you disagree.

> The other way around this is _not_ the case.

What do you mean?

> To say that two things are
> compatible if one can be used for the other, but the other not for the
> first, is false or misleading.

I'm not sure what you mean here. Maybe I didn't make myself clear
enough, but what I mean is this: as long as print and integer division
is concerned, it is trivial to write code that runs on both 2.6 and
3.x. Hence if someone wants to highlight incompatibility (which surely
exists) between 2.6 and 3.x he/she has to look elsewhere.

Daniel Fetchinson

unread,
Jan 27, 2010, 9:30:00 AM1/27/10
to Python

Thanks! This is true, luckily you provided a better solution and the
conclusion is not changed, as long as print is concerned, 2.6 and 3.x
can trivially be made compatible.

Surely there are incompatibilities, but first of all there are many
tools that help the transition such as 2to3 and there is a clear and
officially documented migration guide too (quoted by Steve Holden in
another thread not so long ago), second of all the most vocal
arguments that one hears mostly from ill-informed people are related
to print and similar non-issues. These then get quoted over and over
again, which led me to write this post :)

Cheers,
Daniel

Jean-Michel Pichavant

unread,
Jan 27, 2010, 9:32:17 AM1/27/10
to Daniel Fetchinson, Python
Daniel Fetchinson wrote:
>>> Hi folks,
>>>
>>> I was going to write this post for a while because all sorts of myths
>>> periodically come up on this list about python 3. I don't think the
>>> posters mean to spread false information on purpose, they simply are
>>> not aware of the facts.
>>>
>>> My list is surely incomplete, please feel free to post your favorite
>>> misconception about python 3 that people periodically state, claim or
>>> ask about.
>>>
>>> 1. Print statement/function creates incompatibility between 2.x and 3.x!
>>>
>>> Certainly false or misleading, if one uses 2.6 and 3.x the
>>> incompatibility is not there. Print as a function works in 2.6:
>>>
>>> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
>>> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>>>> print( 'hello' )
>>>>>>
>>> hello
>>>
>>>>>> print 'hello'
>>>>>>
>>> hello
>>>
>>> 2. Integer division creates incompatibility between 2.x and 3.x!
>>>
>>> Again false or misleading, because one can get the 3.x behavior with 2.6:

>>>
>>> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
>>> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
How would you write in python 2.6

if print:
print('Hello')

---

def myPrint(*args):
for arg in args:
sys.stdout.write(str(arg))

print = myPrint

JM

Lie Ryan

unread,
Jan 27, 2010, 9:42:21 AM1/27/10
to


from __future__ import print_function

if print:
print('Hello')

def myPrint(*args):

Eric_...@msn.com

unread,
Jan 27, 2010, 11:11:29 AM1/27/10
to

I can't say that I am that keen on 2.6 all my favorite graphics
libraries are in 2.5. If there was money
involved I would probably think y'all were doing it to stay employed
so I am thinking I should wait till 3.4
and 3.5 to get involved with this but much sooner than python 4.0. I
did notice that I had trouble compiling
a library because some version of microsoft c is no longer
available...sort of forced migration.


______________________________________
http://dextracker.blogspot.com/

John Nagle

unread,
Jan 27, 2010, 3:56:10 PM1/27/10
to
Daniel Fetchinson wrote:
> Hi folks,
>
> I was going to write this post for a while because all sorts of myths
> periodically come up on this list about python 3. I don't think the
> posters mean to spread false information on purpose, they simply are
> not aware of the facts.
>
> My list is surely incomplete, please feel free to post your favorite
> misconception about python 3 that people periodically state, claim or
> ask about.

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.

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.

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.

That's the reality, Python 3 fanboys.

John Nagle

Grant Edwards

unread,
Jan 27, 2010, 3:45:21 PM1/27/10
to
On 2010-01-27, John Nagle <na...@animats.com> wrote:

> Arguably, Python 3 has been rejected by the market.

Let's just say that it hasn't yet been accepted 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.

I think I'd have to wait a couple more years before making that
sort of pronouncement.

That said, I don't expect to start using Python 3 until library
availability or my Linux distro forces me to.

--
Grant Edwards grante Yow! Inside, I'm already
at SOBBING!
visi.com

Adam Tauno Williams

unread,
Jan 27, 2010, 4:06:24 PM1/27/10
to pytho...@python.org
On Wed, 2010-01-27 at 12:56 -0800, John Nagle wrote:
> Daniel Fetchinson wrote:
> > Hi folks,
> > I was going to write this post for a while because all sorts of myths
> > periodically come up on this list about python 3. I don't think the
> > posters mean to spread false information on purpose, they simply are
> > not aware of the facts.
> > My list is surely incomplete, please feel free to post your favorite
> > misconception about python 3 that people periodically state, claim or
> > ask about.
> 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.

CentOS: python26-2.6.4-1.ius.parallel.el5

openSUSE: python-2.6.2-6.3.i586, python3-3.1-3.3.i586

Darn, those pesky facts.

> 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.

And of all Python development what percentage takes place on all those
combined? 2%? Maybe.


sjde...@yahoo.com

unread,
Jan 27, 2010, 4:14:23 PM1/27/10
to
On Jan 27, 9:22 am, Daniel Fetchinson <fetchin...@googlemail.com>
wrote:

I think you're misunderstanding what "compatibility" means in a
programming language context. Python 3 and Python 2 are not mutually
compatible, as arbitrary programs written in one will not run in the
other. The most important fallout of that is that Python 3 is not
backwards compatible, in that existing Python 2 programs won't run
unaltered in Python 3--while it's easy to write a new program in a
subset of the languages that runs on both Python 2 and 3, the huge
existing codebase of Python 2 code won't run under Python 3.

That there exists an intersection of the two languages that is
compatible with both doesn't make the two languages compatible with
each other--although it being a fairly large subset does help mitigate
a sizable chunk of the problems caused by incompatibility (as do tools
like 2to3).

In your example, a python2 program that uses print and division will
fail in python3. The print problem is less significant, since the
failure will probably be a syntax error or a rapid exception raised.
The division problem is more problematic, since a program may appear
to run fine but silently misbehave; such errors are much more likely
to result in significant damage to data or other long-term badness.

Ben Finney

unread,
Jan 27, 2010, 4:20:30 PM1/27/10
to
John Nagle <na...@animats.com> writes:

> 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.

There's a big difference between “What list of versions of Python does
<fooOS> ship with?” versus “Which one version of Python does <fooOS> use
for its implementation of ‘python’?”. I think the latter is the more
pertinent question.

Do you have evidence to back up a claim (not that I'm saying you have
necessarily made the claim; it's not clear from what you wrote) that
most operating systems use Python 2.4 as their implementation of
‘python’?

--
\ “Anyone who believes exponential growth can go on forever in a |
`\ finite world is either a madman or an economist.” —Kenneth |
_o__) Boulding |
Ben Finney

Benjamin Kaplan

unread,
Jan 27, 2010, 4:25:46 PM1/27/10
to pytho...@python.org
On Wed, Jan 27, 2010 at 3:56 PM, John Nagle <na...@animats.com> wrote:
> Daniel Fetchinson wrote:
>>
>> Hi folks,
>>
>> I was going to write this post for a while because all sorts of myths
>> periodically come up on this list about python 3. I don't think the
>> posters mean to spread false information on purpose, they simply are
>> not aware of the facts.
>>
>> My list is surely incomplete, please feel free to post your favorite
>> misconception about python 3 that people periodically state, claim or
>> ask about.
>
> 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.
>
The latest versions of Ubuntu Jaunty and Karmic, Fedora 11 and 12, and
OpenSUSE 11.2 all use Python 2.6. Ubuntu has been shipping python 3
since Jaunty came out last April. According to Fedora's package index,
Python 3 is in the devel version which probably means it will be in
upcoming versions of Fedora as well.


> 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. 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.

> 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.

> That's the reality, Python 3 fanboys.
>
>                                John Nagle

> --
> http://mail.python.org/mailman/listinfo/python-list
>

Christian Heimes

unread,
Jan 27, 2010, 4:26:04 PM1/27/10
to John Nagle, pytho...@python.org
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.
My Ubuntu box has python3.0, too.

> 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.

You are wrong again. We have an active discussion on the Python
developer mailinglist to integrate Unladen Swallow into py3k, see
http://jessenoller.com/2010/01/06/unladen-swallow-python-3s-best-feature/
. The other implementations have been planing Python 3.x support for
more than a year.

>
> 3. Python 3 is supported by most 3rd party Python packages.
>
> FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

Python 3.x has builtin support for several aspects of OpenSSL. Other
important projects like Cython, lxml, some Postgres DBAs, Django,
mod_wsgi and many more have been ported to Python 3.x for more than a
year. In fact Graham has helped us to identify several issues in 3.0
beta while he was porting mod_wsgi to Python 3.0.

(Personally I neither see MySQL as mission critical nor as a powerful
RDBMS. Just try to combine foreign keys with triggers and you'll see
what I'm talking about. *scnr*)

Christian

Ben Finney

unread,
Jan 27, 2010, 4:30:58 PM1/27/10
to

That's irrelevant to the point, though. Regardless of how small the
minority of developers on the platform, it clearly matters to those
developers which versions of Python they can use.

--
\ “When I get new information, I change my position. What, sir, |
`\ do you do with new information?” —John Maynard Keynes |
_o__) |
Ben Finney

Ben Finney

unread,
Jan 27, 2010, 4:50:12 PM1/27/10
to
Christian Heimes <li...@cheimes.de> 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.

Fortunately, Debian Squeeze now finally has added Python 2.6 (though
currently ‘python’ still uses Python 2.5). But Squeeze is currently a
long way from being released.

Python 3 is in the play-pen of Debian “unstable”, but only arrived this
week. It's even further from being released; it has to pass the filter
from “unstable” to “testing” before it gets consideration for that.

So I think your statement above is at least a mischaracterisation of the
truth.

--
\ “As scarce as truth is, the supply has always been in excess of |
`\ the demand.” —Josh Billings |
_o__) |
Ben Finney

Adam Tauno Williams

unread,
Jan 27, 2010, 5:00:56 PM1/27/10
to pytho...@python.org

PostgreSQL support is available for Python3.

Just switch to using a real database and one of you problems is
solved. :)

Carl Banks

unread,
Jan 27, 2010, 5:07:15 PM1/27/10
to
On Jan 27, 12:56 pm, John Nagle <na...@animats.com> wrote:
> Arguably, Python 3 has been rejected by the market.

No it's not fathomably arguable, because there's no reasonable way
that Python 3 could have fully replaced Python 2 so quickly.

At best, you could reasonably argue there hasn't been enough time to
tell.


> Instead, there's
> now Python 2.6, Python 2.7, and Python 2.8.

It was always the plan to continue developing Python 2.x alongside
Python 3.x during the transition period.

Last I heard, don't remember where, the plan was for Python 2.7 to be
the last version in the Python 2 line. If that's true, Python 3
acceptance is further along at this point than anticipated, since they
originally thought they might have to go up to 2.9.


> Python 3 has turned into
> a debacle like Perl 6, now 10 years old.

Perl 6 has never been released. The situations aren't even
comparable.


> That's the reality, Python 3 fanboys.

You're the fanboy, fanboi. You are so hellbent on badmouthing Python
3 that you throw three ridiculous, straw-grasping arguments at us.

Here's the real reality.

Python 3 is going to replace Python 2, and it has nothing to do with
technical merit. The developers are planning to stop development on
2.x line, and only continue with 3.x, so anyone who wants to stay
current--which is most people--with Python will have to use 3.x.
There is no hope that developers will be pressured by the market to
change their plans; we would have seen enough of a backlash by now.
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. No, don't be silly, a fork of Python not
called Python won't gain market share.

So rail if it makes you feel better but you've already lost.


Carl Banks

exa...@twistedmatrix.com

unread,
Jan 27, 2010, 5:19:00 PM1/27/10
to Carl Banks, pytho...@python.org
On 10:07 pm, pavlove...@gmail.com wrote:
>On Jan 27, 12:56 pm, John Nagle <na...@animats.com> wrote:
>>Arguably, Python 3 has been rejected by the market.
>
>No it's not fathomably arguable, because there's no reasonable way
>that Python 3 could have fully replaced Python 2 so quickly.
>
>At best, you could reasonably argue there hasn't been enough time to
>tell.
>> Instead, there's
>>now Python 2.6, Python 2.7, and Python 2.8.
>
>It was always the plan to continue developing Python 2.x alongside
>Python 3.x during the transition period.
>
>Last I heard, don't remember where, the plan was for Python 2.7 to be
>the last version in the Python 2 line. If that's true, Python 3
>acceptance is further along at this point than anticipated, since they
>originally thought they might have to go up to 2.9.

This assumes that the decision to stop making new 2.x releases is based
on Python 3 adoption, rather than on something else. As far as I can
tell, it's based on the personal desire of many of the core developers
to stop bothering with 2.x. In other words, it's more a gauge of
adoption of Python 3 amongst Python core developers.

Jean-Paul

Mensanator

unread,
Jan 27, 2010, 5:24:38 PM1/27/10
to
On Jan 27, 2:56 pm, John Nagle <na...@animats.com> wrote:
> Daniel Fetchinson wrote:
> > Hi folks,
>
> > I was going to write this post for a while because all sorts of myths
> > periodically come up on this list about python 3. I don't think the
> > posters mean to spread false information on purpose, they simply are
> > not aware of the facts.
>
> > My list is surely incomplete, please feel free to post your favorite
> > misconception about python 3 that people periodically state, claim or
> > ask about.
>
> 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.

So? I use Mac OSX 10.6, not Linux. And that comes with 2.6.
Nothing stopped me from adding 3.1.

>
> 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.

So? I only use CPython.

>
> 3.  Python 3 is supported by most 3rd party Python packages.
>
>         FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

So? The only 3rd party module I use is gmpy, and that's been updated
to 3.x.

>
> 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.

Maybe in *your* world. I'm perfectly happy in my world using 3.1.

>
>                                 John Nagle

Terry Reedy

unread,
Jan 27, 2010, 5:34:23 PM1/27/10
to pytho...@python.org
On 1/27/2010 3:56 PM, John Nagle 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.

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.

> Arguably, Python 3 has been rejected by the market.

Almost everything is 'arguable'. Based on experience, Guido never
expected major uptake until 3.2 (a year away).

> Instead, there's now Python 2.6,

Just who produced that? and why?

> Python 2.7,

Does not exist yet, but again, coming from the same devs for the purpose
of helping transition to 3.x.

> and Python 2.8.

Unlikely to ever exist.

> Python 3 has turned into a debacle like Perl 6, now 10 years old.

You have to wait another 9 years to really say that. However, my
impression is that Python 3 alreays surpasses Perl 6.

> That's the reality, Python 3 fanboys.

Why are you such a Python 3 hateboy?

Terry Jan Reedy

Daniel Fetchinson

unread,
Jan 27, 2010, 6:38:14 PM1/27/10
to Python
>> Hi folks,
>>
>> I was going to write this post for a while because all sorts of myths
>> periodically come up on this list about python 3. I don't think the
>> posters mean to spread false information on purpose, they simply are
>> not aware of the facts.
>>
>> My list is surely incomplete, please feel free to post your favorite
>> misconception about python 3 that people periodically state, claim or
>> ask about.
>
> Myths about Python 3:

I said myths, not facts! :)

s/Myths/Facts/



> 1. Python 3 is supported by major Linux distributions.
>
> FALSE - most distros are shipping with Python 2.4, or 2.5 at best.

This latter statement is false, Fedora 11 and 12 come with python 2.6.

> 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.

This latter statement is false, unladen swallow is currently targeting
3.x and may even be merged into cpython 3.x.

> 3. Python 3 is supported by most 3rd party Python packages.
>
> FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.

s/most/my favorite/

Actually, tons of 3rd party packages are already ported, postgres and
django are just 2 examples, the next release of PIL will be another.

> 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.

These are the kinds of myths I had in mind when starting the thread.
All sorts of BS is kept circulating without any facts to back up the
claims. Actually, in this thread tons of rebuttals can be found to
your statements but I doubt you will change your mind :) Hopefully
others reading all of this will at least see what is BS and what is
the actual situation about python 3.

David Malcolm

unread,
Jan 27, 2010, 5:58:54 PM1/27/10
to Benjamin Kaplan, pytho...@python.org
On Wed, 2010-01-27 at 16:25 -0500, Benjamin Kaplan wrote:
> On Wed, Jan 27, 2010 at 3:56 PM, John Nagle <na...@animats.com> wrote:
> > Daniel Fetchinson wrote:
> >>
> >> Hi folks,
> >>
> >> I was going to write this post for a while because all sorts of myths
> >> periodically come up on this list about python 3. I don't think the
> >> posters mean to spread false information on purpose, they simply are
> >> not aware of the facts.
> >>
> >> My list is surely incomplete, please feel free to post your favorite
> >> misconception about python 3 that people periodically state, claim or
> >> ask about.
> >
> > 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.
> >
> The latest versions of Ubuntu Jaunty and Karmic, Fedora 11 and 12, and
> OpenSUSE 11.2 all use Python 2.6. Ubuntu has been shipping python 3
> since Jaunty came out last April. According to Fedora's package index,
> Python 3 is in the devel version which probably means it will be in
> upcoming versions of Fedora as well.

FWIW, more information on Fedora python 3 status here:
https://fedoraproject.org/wiki/Features/Python3F13

[snip]

> 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'll take this opportunity to make a shameless plug for my 2to3c tool:
http://dmalcolm.livejournal.com/3935.html

which takes some of the grunt work out of taking C code and making it
compilable against both 2 and 3. (it will still require a human to do
some of the work, alas).


Hope this is helpful
Dave

Edward A. Falk

unread,
Jan 27, 2010, 6:50:19 PM1/27/10
to
In article <mailman.1470.1264588...@python.org>,

Daniel Fetchinson <fetch...@googlemail.com> wrote:
>Hi folks,
>
>1. Print statement/function creates incompatibility between 2.x and 3.x!
>
>Certainly false or misleading, if one uses 2.6 and 3.x the
>incompatibility is not there. Print as a function works in 2.6:

Yes, but does print as a statement work?

Your argument is that python 2.x code can be ported to 3.x and still
run under 2.6 if you're careful about how you do the port. That's
not the same as saying they're compatible.


>2. Integer division creates incompatibility between 2.x and 3.x!

Same as above. Saying you can make it work by rewriting your code
is not the same as saying that it works.


If they'd wanted wide adoption of python 3, they should have made it
as compatible as possible with python 2 code. If they dropped the
print statement, then they did not do so.
--
-Ed Falk, fa...@despams.r.us.com
http://thespamdiaries.blogspot.com/

Edward A. Falk

unread,
Jan 27, 2010, 6:52:07 PM1/27/10
to
In article <hjq8l0$ge5$1...@reader1.panix.com>,

Grant Edwards <inv...@invalid.invalid> wrote:
>
>That said, I don't expect to start using Python 3 until library
>availability or my Linux distro forces me to.

If python 3 is much more efficient than python 2, or it has features
I really need for some application I'll write in the future, I might
be tempted to switch. Maybe some future version of python 3 will
be compatible with python 2 source code. That would help.

Ethan Furman

unread,
Jan 27, 2010, 7:14:53 PM1/27/10
to Python
Daniel Fetchinson wrote:
>>> Hi folks,
>>>
>>> I was going to write this post for a while because all sorts of myths
>>> periodically come up on this list about python 3. I don't think the
>>> posters mean to spread false information on purpose, they simply are
>>> not aware of the facts.
>>>
>>> My list is surely incomplete, please feel free to post your favorite
>>> misconception about python 3 that people periodically state, claim or
>>> ask about.
>>>
>>> 1. Print statement/function creates incompatibility between 2.x and 3.x!
>>>
>>> Certainly false or misleading, if one uses 2.6 and 3.x the
>>> incompatibility is not there. Print as a function works in 2.6:
>>>
>>> Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
>>> [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> print( 'hello' )
>>> hello
>>>>>> print 'hello'
>>> hello
>>>
>>> 2. Integer division creates incompatibility between 2.x and 3.x!
>>>
> Cheers,
> Daniel
>

I think what Andre is saying is that you can't get 2.x behavior in 3.x,
only the other way 'round.

In the integer division instance, the 2.x behavior of 6/5 = 1 is not
going to happen in 3.x.

~Ethan~

Steven D'Aprano

unread,
Jan 27, 2010, 7:19:24 PM1/27/10
to
On Wed, 27 Jan 2010 12:56:10 -0800, John Nagle wrote:

> Daniel Fetchinson wrote:
>> Hi folks,
>>
>> I was going to write this post for a while because all sorts of myths
>> periodically come up on this list about python 3. I don't think the
>> posters mean to spread false information on purpose, they simply are
>> not aware of the facts.
>>
>> My list is surely incomplete, please feel free to post your favorite
>> misconception about python 3 that people periodically state, claim or
>> ask about.
>
> Myths about Python 3:
>
> 1. Python 3 is supported by major Linux distributions.

> 2. Python 3 is supported by multiple Python implementations.

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

A myth actually needs to be believed by some sector of the population,
even if a small one. (Isolated nut cases don't count.) Star Wars is not a
myth, because nobody -- not even those wacky people who put down "Jedi"
as their religion on census forms -- actually believes it is a
documentary.

I've never heard anyone claiming any of those three "myths". I conclude
that you just made them up, that they are fictional claims rather than
genuine myths mistakenly believed by some people. So, in that spirit,
here are three more for your collection. Perhaps you could start a list
on a website somewhere.

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.

5. Python 3 programs cannot be buggy, no matter how poorly you code.

FALSE - programs written in Python 3 can contain bugs.

6. The code for Python 3 was handed down to Guido from the Heavens,
carved into stone tablets by the Gods themselves.

FALSE - Python 3 was designed and written by fallible human beings,
and consequently there is no guarantee that it will be perfect in
all ways for all purposes.

> That's the reality, Python 3 fanboys.

Speaks for itself.

--
Steven

Carl Banks

unread,
Jan 27, 2010, 7:32:39 PM1/27/10
to
On Jan 27, 2:19 pm, exar...@twistedmatrix.com wrote:

> On 10:07 pm, pavlovevide...@gmail.com wrote:
> >Last I heard, don't remember where, the plan was for Python 2.7 to be
> >the last version in the Python 2 line.  If that's true, Python 3
> >acceptance is further along at this point than anticipated, since they
> >originally thought they might have to go up to 2.9.
>
> This assumes that the decision to stop making new 2.x releases is based
> on Python 3 adoption, rather than on something else.

I should have said, "If anything...".


Carl Banks

Paul Rubin

unread,
Jan 27, 2010, 7:28:08 PM1/27/10
to
Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes:
> 6. The code for Python 3 was handed down to Guido from the Heavens,
> carved into stone tablets by the Gods themselves.

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

Steven D'Aprano

unread,
Jan 27, 2010, 7:35:42 PM1/27/10
to
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.

THANK YOU Benjamin for injecting this note of sanity into the discussion.

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.

Certainly the move from 2.x to 3.x is a big move. If you have to support
both series simultaneously, I don't envy your job, but if CherryPy can do
it, so can others. But it's not qualitatively different from supporting
(say) 2.4 through 2.6. Targeting multiple versions is always a PITA.

I also find it telling that perhaps the biggest change of all, the one
from byte strings to unicode, hardly rates a mention from the skeptics
and haters. Instead we get rants about how division behaves differently
(forgetting that "from __future__ import division" has worked since at
least 2.4 and possibly older) and complaints that print is different.

--
Steven

alex23

unread,
Jan 27, 2010, 8:36:29 PM1/27/10
to
Terry Reedy <tjre...@udel.edu> wrote:
> 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

unread,
Jan 27, 2010, 8:46:12 PM1/27/10
to


SPLITTER!!!

--
Steven

Carl Banks

unread,
Jan 27, 2010, 8:59:39 PM1/27/10
to
On Jan 27, 5:36 pm, alex23 <wuwe...@gmail.com> wrote:
> Terry Reedy <tjre...@udel.edu> wrote:
> > 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?

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

unread,
Jan 27, 2010, 9:18:33 PM1/27/10
to
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

unread,
Jan 27, 2010, 9:37:21 PM1/27/10
to John Nagle, pytho...@python.org
John Nagle wrote:
> Daniel Fetchinson wrote:
>> Hi folks,
>>
>> I was going to write this post for a while because all sorts of myths
>> periodically come up on this list about python 3. I don't think the
>> posters mean to spread false information on purpose, they simply are
>> not aware of the facts.
>>
>> My list is surely incomplete, please feel free to post your favorite
>> misconception about python 3 that people periodically state, claim or
>> ask about.
>
> 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 +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

Steve Holden

unread,
Jan 27, 2010, 9:37:21 PM1/27/10
to pytho...@python.org, pytho...@python.org

Paul Rubin

unread,
Jan 27, 2010, 9:44:05 PM1/27/10
to
Steve Holden <st...@holdenweb.com> writes:
> 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

unread,
Jan 28, 2010, 1:39:14 AM1/28/10
to pytho...@python.org
On 1/27/2010 8:36 PM, alex23 wrote:
> Terry Reedy<tjre...@udel.edu> wrote:
>> Actually, Unladen Swallow is now targeted at 3.1; its developers have
>> conservatively proposed its integration in CPython 3.3.

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

>> I would not be completely shocked if it happens in 3.2.

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

unread,
Jan 28, 2010, 3:00:23 AM1/28/10
to
Benjamin Kaplan, 27.01.2010 22:25:

> On Wed, Jan 27, 2010 at 3:56 PM, John Nagle <na...@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

Stefan Behnel

unread,
Jan 28, 2010, 3:11:31 AM1/28/10
to
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

Paul Rubin

unread,
Jan 28, 2010, 3:40:09 AM1/28/10
to
Stefan Behnel <stef...@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.

Aahz

unread,
Jan 28, 2010, 11:06:33 AM1/28/10
to
In article <pan.2010.01...@REMOVE.THIS.cybersource.com.au>,

Steven D'Aprano <ste...@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 (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

import antigravity

Aahz

unread,
Jan 28, 2010, 11:10:15 AM1/28/10
to
In article <Zt68n.3893$pv....@news-server.bigpond.net.au>,

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

unread,
Jan 28, 2010, 11:37:24 AM1/28/10
to Stefan Behnel, pytho...@python.org
Stefan wrote:
> >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.)

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

unread,
Jan 28, 2010, 11:52:19 AM1/28/10
to pytho...@python.org
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

unread,
Jan 28, 2010, 11:55:29 AM1/28/10
to pytho...@python.org
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.

Carl Banks

unread,
Jan 28, 2010, 1:21:52 PM1/28/10
to
On Jan 28, 8:10 am, a...@pythoncraft.com (Aahz) wrote:
> In article <Zt68n.3893$pv.1...@news-server.bigpond.net.au>,

> Neil Hodgson  <nyamatongwe+thun...@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.

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

unread,
Jan 28, 2010, 2:51:48 PM1/28/10
to Carl Banks, pytho...@python.org
But if it were sanctioned ... ? We *are* pretty magnanimous ;-)

Steve Holden

unread,
Jan 28, 2010, 2:51:48 PM1/28/10
to pytho...@python.org, pytho...@python.org

Terry Reedy

unread,
Jan 28, 2010, 4:21:59 PM1/28/10
to pytho...@python.org
On 1/28/2010 2:51 PM, Steve Holden wrote:
> Carl Banks wrote:

>> 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 ;-)

I think it foolish to speculate in the absence of specifics. If some
people wanted to coninue bug-fix maintainance of 2.7 after the main
group of developers is done with it, in 5 years, then no new name is
needed. If some people wanted to backport additional 3.x features, while
still keeping the old, obsolete stuff around, then '2.8' would be
appropriate. If some people wanted to add a collection of incompatible
new features, perhaps some that Guido has rejected for 'Python', so that
they were producing a real fork, then a new name should be used.

I consider the first option possible, assuming that significant bugs
still remain in 5 years. The second seems more dubious, as the
developers have already backported most of what they thought sensible.
The third has always been possible, and has been done, and there would
be nothing really special about using 2.7 as a base.

Terry Jan Reedy

Ethan Furman

unread,
Jan 28, 2010, 12:35:53 PM1/28/10
to pytho...@python.org
Steven D'Aprano wrote:
> 4. Python 3 will make you irresistible to women.
>
> FALSE

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

~Ethan~

Ben Finney

unread,
Jan 28, 2010, 4:33:58 PM1/28/10
to
Antoine Pitrou <soli...@pitrou.net> writes:

> 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) :-)

Perhaps Steven could tell you about a lovely Australian meaning for the
word “date”.

--
\ “Even if the voices in my head are not real, they have pretty |
`\ good ideas.” —anonymous |
_o__) |
Ben Finney

Mensanator

unread,
Jan 28, 2010, 6:49:55 PM1/28/10
to

Irresisible? Ha! The chicks will think you have a harelip.

>
> ~Ethan~

Gib Bogle

unread,
Jan 28, 2010, 7:57:18 PM1/28/10
to

Learn to say this fast, you'll impress the hell out of them:

Chaps with chapped lips lisp.

Steven D'Aprano

unread,
Jan 28, 2010, 8:20:03 PM1/28/10
to
On Fri, 29 Jan 2010 08:33:58 +1100, Ben Finney wrote:

> Antoine Pitrou <soli...@pitrou.net> writes:
>
>> 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) :-)
>
> Perhaps Steven could tell you about a lovely Australian meaning for the
> word “date”.

This is a family list, so perhaps I shouldn't. :)

In Australia slang, "date" is short for "date hole", which is the part of
the anatomy which is also known as "the [one] brown eye". In parts of the
US, it is also known as the "corn hole", and in Cockney rhyming slang it
is a jam role.

I trust I don't need to be any more explicit...

--
Steven

Ben Finney

unread,
Jan 28, 2010, 9:16:11 PM1/28/10
to

I think the reason “date” was initially used is because dates are most
familiar to us as fleshy, dark brown, wrinkled, compressed points.

My interests in etymology and scatology unite here.

--
\ “In the long run, the utility of all non-Free software |
`\ approaches zero. All non-Free software is a dead end.” —Mark |
_o__) Pilgrim, 2006 |
Ben Finney

Steve Holden

unread,
Jan 28, 2010, 9:26:04 PM1/28/10
to pytho...@python.org
My God, and I just nominated you for membership of the PSF.

Trust an Australian to descend to normally unplumbed depths (pun
intended) the very second you stake your reputation on them. I guess
that means I know my place ...

there-goes-my-american-citizenship-ly y'rs - steve

alex23

unread,
Jan 28, 2010, 9:56:11 PM1/28/10
to
Terry Reedy <tjre...@udel.edu> wrote:
> This statement was to counter the 'myth' that US was only targeted at
> 2.x when the current situation is quite the opposite.

Not so much 'myth' as 'outdated information', they were very clear
that 2.x was the initial target.

> 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.

Ah, that's excellent. The impression being given off is that it's a
total replacement.

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

It's not so much about being surprised or not, it's wanting actual
evidence and not just claims, and moreso _extensive real world usage_
before it's integrated. This seems far more intimate a change than
adding a module to the stdlib, I expect it to have at _least_ the
evaluation time & vague consensus of approval expected of those.

> 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.

As long as there aren't any related decreases in performance in other
areas, I'll be happy.

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

Well, I didn't know I could, so now I don't quite as much :)

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

Maybe I'll be a lot more convinced after the Q4 report.

The 'incomplete' Windows support may not be as big an issue as I
thought, it seems to refer to a lack of support for older Windows
versions rather than an incomplete implementation on the supported
ones.

Cheers, Terry, this addressed a lot of my concerns, although I'm still
keen to see more facts & real-world usage over custom-crafted
benchmarks and enthusiastic claims.

Tim Roberts

unread,
Jan 29, 2010, 12:21:05 AM1/29/10
to
John Nagle <na...@animats.com> wrote:
>
>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.

Although I happen to be one of the folks who are reluctant to switch to
Python 3, I have to say that this comparison is entirely unfair. Python 3
exists in the wild. It has been released, and has even had a couple of
updates. Eventually, it will prevail. Resistance is futile, you WILL be
assimilated.

Perl 6, on the other hand, is still fantasyware a decade after its
announcement. It is, for the most part, THE canonical example of the wrong
way to conduct a development effort.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.