Discussion:
myths about python 3
Daniel Fetchinson
2010-01-27 10:32:08 UTC
Permalink
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
2010-01-27 10:40:27 UTC
Permalink
Post by Daniel Fetchinson
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
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.
Post by Daniel Fetchinson
print(1,2)
(1, 2)
Post by Daniel Fetchinson
from __future__ import print_function
print(1,2)
1 2

Stefan
Daniel Fetchinson
2010-01-27 14:30:00 UTC
Permalink
Post by Stefan Behnel
Post by Daniel Fetchinson
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
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
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.
Post by Daniel Fetchinson
print(1,2)
(1, 2)
Post by Daniel Fetchinson
from __future__ import print_function
print(1,2)
1 2
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


Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Andre Engels
2010-01-27 10:45:48 UTC
Permalink
On Wed, Jan 27, 2010 at 11:32 AM, Daniel Fetchinson
Post by Daniel Fetchinson
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
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!
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, andreengels at gmail.com
Daniel Fetchinson
2010-01-27 14:22:39 UTC
Permalink
Post by Andre Engels
Post by Daniel Fetchinson
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
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!
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.
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.
Post by Andre Engels
The other way around this is _not_ the case.
What do you mean?
Post by Andre Engels
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.

Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Jean-Michel Pichavant
2010-01-27 14:32:17 UTC
Permalink
Post by Daniel Fetchinson
Post by Andre Engels
Post by Daniel Fetchinson
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
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!
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.
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.
Post by Andre Engels
The other way around this is _not_ the case.
What do you mean?
Post by Andre Engels
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.
Cheers,
Daniel
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
2010-01-27 14:42:21 UTC
Permalink
Post by Jean-Michel Pichavant
Post by Daniel Fetchinson
Post by Andre Engels
Post by Daniel Fetchinson
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
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!
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.
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.
Post by Andre Engels
The other way around this is _not_ the case.
What do you mean?
Post by Andre Engels
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.
Cheers,
Daniel
How would you write in python 2.6
print('Hello')
---
sys.stdout.write(str(arg))
print = myPrint
JM
from __future__ import print_function

if print:
print('Hello')

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

print = myPrint
Eric_Dexter
2010-01-27 16:11:29 UTC
Permalink
Post by Jean-Michel Pichavant
Post by Daniel Fetchinson
Post by Andre Engels
Post by Daniel Fetchinson
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
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!
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.
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.
Post by Andre Engels
The other way around this is _not_ the case.
What do you mean?
Post by Andre Engels
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.
Cheers,
Daniel
How would you write in python 2.6
? ?print('Hello')
---
? ? ? ?sys.stdout.write(str(arg))
print = myPrint
JM
from __future__ import print_function
? ? print('Hello')
? ? ? ?sys.stdout.write(str(arg))
print = myPrint
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/
Ethan Furman
2010-01-28 00:14:53 UTC
Permalink
Post by Daniel Fetchinson
Post by Andre Engels
Post by Daniel Fetchinson
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
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!
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.
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.
Post by Andre Engels
The other way around this is _not_ the case.
What do you mean?
Post by Andre Engels
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.
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~
sjdevnull
2010-01-27 21:14:23 UTC
Permalink
On Jan 27, 9:22?am, Daniel Fetchinson <fetchin... at googlemail.com>
Post by Daniel Fetchinson
Post by Andre Engels
Post by Daniel Fetchinson
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
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!
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.
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.
Post by Andre Engels
The other way around this is _not_ the case.
What do you mean?
Post by Andre Engels
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.
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.
Grant Edwards
2010-01-27 20:45:21 UTC
Permalink
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
Edward A. Falk
2010-01-27 23:52:07 UTC
Permalink
In article <hjq8l0$ge5$1 at reader1.panix.com>,
Post by Grant Edwards
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.
--
-Ed Falk, falk at despams.r.us.com
http://thespamdiaries.blogspot.com/
John Nagle
2010-01-27 20:56:10 UTC
Permalink
Post by Daniel Fetchinson
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
Adam Tauno Williams
2010-01-27 21:06:24 UTC
Permalink
Post by John Nagle
Post by Daniel Fetchinson
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. 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.
Post by John Nagle
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.
Ben Finney
2010-01-27 21:20:30 UTC
Permalink
Post by John Nagle
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
2010-01-27 21:25:46 UTC
Permalink
Post by Daniel Fetchinson
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. ?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
Adam Tauno Williams
2010-01-27 22:00:56 UTC
Permalink
Post by Benjamin Kaplan
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.
PostgreSQL support is available for Python3.

Just switch to using a real database and one of you problems is
solved. :)
David Malcolm
2010-01-27 22:58:54 UTC
Permalink
Post by Benjamin Kaplan
Post by John Nagle
Post by Daniel Fetchinson
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. 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]
Post by Benjamin Kaplan
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
Christian Heimes
2010-01-27 21:26:04 UTC
Permalink
Post by John Nagle
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.
Post by John Nagle
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.
Post by John Nagle
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
2010-01-27 21:30:58 UTC
Permalink
Post by Adam Tauno Williams
Post by John Nagle
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?
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
2010-01-27 21:50:12 UTC
Permalink
Post by Christian Heimes
Post by John Nagle
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
Stefan Behnel
2010-01-28 08:11:31 UTC
Permalink
Post by Ben Finney
Post by Christian Heimes
Post by John Nagle
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
Anssi Saari
2010-01-29 13:00:08 UTC
Permalink
Post by Stefan Behnel
'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.
Yes, but that's beside the point. No released version of Debian ships
with Python3 or even 2.6.

Oh, and RHEL5 and CentOS5 ship with 2.4.
Carl Banks
2010-01-27 22:07:15 UTC
Permalink
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
exarkun
2010-01-27 22:19:00 UTC
Permalink
Post by Carl Banks
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
Carl Banks
2010-01-28 00:32:39 UTC
Permalink
Post by exarkun
Post by Carl Banks
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
Neil Hodgson
2010-01-28 02:18:33 UTC
Permalink
Post by 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
Aahz
2010-01-28 16:10:15 UTC
Permalink
In article <Zt68n.3893$pv.1546 at news-server.bigpond.net.au>,
Post by Neil Hodgson
Post by 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 at pythoncraft.com) <*> http://www.pythoncraft.com/

import antigravity
Carl Banks
2010-01-28 18:21:52 UTC
Permalink
In article <Zt68n.3893$pv.1... at news-server.bigpond.net.au>,
Post by 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
2010-01-28 19:51:48 UTC
Permalink
Post by Carl Banks
In article <Zt68n.3893$pv.1... at news-server.bigpond.net.au>,
Post by Neil Hodgson
Post by 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.
But if it were sanctioned ... ? We *are* pretty magnanimous ;-)

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/
Terry Reedy
2010-01-28 21:21:59 UTC
Permalink
Post by Steve Holden
Post by Carl Banks
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
Steve Holden
2010-01-28 19:51:48 UTC
Permalink
Post by Carl Banks
In article <Zt68n.3893$pv.1... at news-server.bigpond.net.au>,
Post by Neil Hodgson
Post by 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.
But if it were sanctioned ... ? We *are* pretty magnanimous ;-)

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/
Martin v. Loewis
2010-01-29 08:25:15 UTC
Permalink
Post by Carl Banks
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.
I'd like to point out that the PSF formally doesn't have any say in
this.

Instead, releases are created by the release manager, who gets appointed
by Guido van Rossum. Those two listen primarily to the opinions of the
fellow committers (which may or may not happen to be PSF members as
well).
Post by Carl Banks
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.
However, calling it "Passive Python", or "John Smith Python", for
example, would certainly be fine. Calling something "Python 2.8"
may not be unreasonable, also "Python 2.9", but surely "Python 2.10"
will hit strong objections (GvR always announced that there will
never be a two-digit minor release number).

Regards,
Martin
Carl Banks
2010-01-29 22:23:48 UTC
Permalink
Post by Martin v. Loewis
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.
I'd like to point out that the PSF formally doesn't have any say in
this.
Doesn't PSF own the Python trademark? Then it has to have a say, not
over whether someone can fork the project or make another official
release, but over whether they can do so and still call it Python.


Carl Banks
Mensanator
2010-01-27 22:24:38 UTC
Permalink
Post by Daniel Fetchinson
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. ?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
2010-01-27 22:34:23 UTC
Permalink
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
2010-01-27 23:38:14 UTC
Permalink
Post by John Nagle
Post by Daniel Fetchinson
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.
I said myths, not facts! :)

s/Myths/Facts/
Post by John Nagle
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.
Post by John Nagle
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.
Post by John Nagle
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.
Post by John Nagle
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.

Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Steven D'Aprano
2010-01-28 00:19:24 UTC
Permalink
Post by John Nagle
Post by Daniel Fetchinson
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. 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.
Post by John Nagle
That's the reality, Python 3 fanboys.
Speaks for itself.
--
Steven
Paul Rubin
2010-01-28 00:28:08 UTC
Permalink
Post by Steven D'Aprano
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
2010-01-28 01:46:12 UTC
Permalink
Post by Paul Rubin
Post by Steven D'Aprano
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.
SPLITTER!!!
--
Steven
Antoine Pitrou
2010-01-28 16:52:19 UTC
Permalink
Post by Steven D'Aprano
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.
Ethan Furman
2010-01-28 17:35:53 UTC
Permalink
Post by Steven D'Aprano
4. Python 3 will make you irresistible to women.
FALSE
What?!? Drat!!! Guess I'll have to learn Lisp... ;)

~Ethan~
Ben Finney
2010-01-28 21:33:58 UTC
Permalink
Post by Antoine Pitrou
Post by Steven D'Aprano
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
Steven D'Aprano
2010-01-29 01:20:03 UTC
Permalink
Post by Ben Finney
Post by Antoine Pitrou
Post by Steven D'Aprano
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
2010-01-29 02:16:11 UTC
Permalink
Post by Steven D'Aprano
Post by Ben Finney
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...
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
Antoine Pitrou
2010-01-29 11:55:02 UTC
Permalink
Post by Ben Finney
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.
Ah, I suppose it explains the strange ASCII art drawing in your signature
then?

(Here)
|
|
v
Post by Ben Finney
--
\ ?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
2010-01-29 02:26:04 UTC
Permalink
Post by Steven D'Aprano
Post by Ben Finney
Post by Antoine Pitrou
Post by Steven D'Aprano
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...
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
--
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/
Mensanator
2010-01-28 23:49:55 UTC
Permalink
Post by Steven D'Aprano
4. Python 3 will make you irresistible to women.
? ? FALSE
What?!? ?Drat!!! ?Guess I'll have to learn Lisp... ?;)
Irresisible? Ha! The chicks will think you have a harelip.
~Ethan~
Gib Bogle
2010-01-29 00:57:18 UTC
Permalink
Post by Ethan Furman
Post by Steven D'Aprano
4. Python 3 will make you irresistible to women.
FALSE
What?!? Drat!!! Guess I'll have to learn Lisp... ;)
~Ethan~
Learn to say this fast, you'll impress the hell out of them:

Chaps with chapped lips lisp.
Steven D'Aprano
2010-01-28 00:35:42 UTC
Permalink
Post by Benjamin Kaplan
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
Aahz
2010-01-28 16:06:33 UTC
Permalink
In article <pan.2010.01.28.00.35.41 at REMOVE.THIS.cybersource.com.au>,
Post by Steven D'Aprano
Post by Benjamin Kaplan
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 at pythoncraft.com) <*> http://www.pythoncraft.com/

import antigravity
Martin v. Loewis
2010-01-29 08:16:17 UTC
Permalink
Post by Steven D'Aprano
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.
I think this is actually false for the switch from 1.5 to 2.0. People
complained a lot, and announced that they won't switch to Python 2 in
any foreseeable future, and indeed, they stayed with Python 1.5.2 for
several years after Python 2 was released.

Of course, the Python user base was much smaller then than it is now,
so the absolute number of complainers surely was never as high is it
is now. Only when Python 4 gets released, even more people will complain
and announce that Python 4 has failed and that they stay with Python
3.8 forever.

Regards,
Martin
alex23
2010-01-28 01:36:29 UTC
Permalink
Post by Terry Reedy
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.
Carl Banks
2010-01-28 01:59:39 UTC
Permalink
Post by alex23
Post by Terry Reedy
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
Terry Reedy
2010-01-28 06:39:14 UTC
Permalink
Post by alex23
Post by Terry Reedy
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.
Post by alex23
Post by Terry Reedy
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.
Post by alex23
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.
Post by alex23
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.
Post by alex23
pretty much kills dead a lot of my interest.
If you can still have a binary free of the traceoff, why would you care?
Post by alex23
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
Antoine Pitrou
2010-01-28 16:55:29 UTC
Permalink
Post by alex23
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.
alex23
2010-01-29 02:56:11 UTC
Permalink
Post by 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.
Not so much 'myth' as 'outdated information', they were very clear
that 2.x was the initial target.
Post by Terry Reedy
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.
Post by Terry Reedy
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.
Post by Terry Reedy
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.
Post by Terry Reedy
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 :)
Post by Terry Reedy
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.
Martin v. Loewis
2010-01-29 08:33:45 UTC
Permalink
Post by alex23
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?
Because it's a VM change, not an end-user change. VM changes can be
reviewed and evaluated by core developers, without requiring necessarily
feedback from end users (although end users can and do certainly
evaluate VM changes themselves also and provide feedback).

For library changes, it's more difficult to evaluate them, because
you not only need to find out whether the change is correct, but also
whether it is useful.
Post by alex23
Are we really expected to just ditch everything we know about
CPython's performance characteristics just for some questionable and
possibly uneven gains?
That's the point of writing a PEP. Provide feedback to the PEP authors,
and ask them to incorporate your objections into the PEP in case they
forget. Then, when the PEP is about to be approved, that feedback
gets taken into consideration.

Posting in the 665th message on a Usenet thread is unlikely to have any
effect on the PEP process, though.
Post by alex23
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.
It's not a claim, it's a PEP. Not being interested in the PEP process
is your choice, of course, but you shouldn't complain afterwards that
your opinion wasn't considered if you didn't actually voice it
appropriately.

Regards,
Martin
Ben Finney
2010-01-29 08:48:26 UTC
Permalink
Not being interested in the PEP process is your choice, of course, but
you shouldn't complain afterwards that your opinion wasn't considered
if you didn't actually voice it appropriately.
+1 QOTW
--
\ ?I installed a skylight in my apartment. The people who live |
`\ above me are furious!? ?Steven Wright |
_o__) |
Ben Finney
Steve Holden
2010-01-28 02:37:21 UTC
Permalink
Post by John Nagle
Post by Daniel Fetchinson
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. 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?
Post by John Nagle
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.
Post by John Nagle
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.
Post by John Nagle
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
2010-01-28 02:37:21 UTC
Permalink
Post by John Nagle
Post by Daniel Fetchinson
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. 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?
Post by John Nagle
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.
Post by John Nagle
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.
Post by John Nagle
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/
Paul Rubin
2010-01-28 02:44:05 UTC
Permalink
Post by Steve Holden
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?
Blog
2010-01-30 03:50:39 UTC
Permalink
Post by Paul Rubin
Post by Steve Holden
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?
There's a prime example - it's called Windows Vista! ;)
Stefan Behnel
2010-01-28 08:00:23 UTC
Permalink
Post by Benjamin Kaplan
Post by John Nagle
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.)
Post by Benjamin Kaplan
Post by John Nagle
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
Paul Rubin
2010-01-28 08:40:09 UTC
Permalink
Post by Stefan Behnel
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.
Dino Viehland
2010-01-28 16:37:24 UTC
Permalink
Post by Stefan Behnel
Post by Benjamin Kaplan
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.
Tim Roberts
2010-01-29 05:21:05 UTC
Permalink
Post by John Nagle
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, timr at probo.com
Providenza & Boekelheide, Inc.
Steven D'Aprano
2010-01-29 05:34:01 UTC
Permalink
Post by Tim Roberts
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.
Out of curiosity, and completely off-topic, why has Perl 6 gone so badly?
--
Steven
geremy condra
2010-01-29 06:02:46 UTC
Permalink
On Fri, Jan 29, 2010 at 12:34 AM, Steven D'Aprano
Post by Steven D'Aprano
Post by Tim Roberts
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.
Out of curiosity, and completely off-topic, why has Perl 6 gone so badly?
--
Steven
--
Too much like Perl.

Geremy Condra
Chris Rebert
2010-01-29 06:07:35 UTC
Permalink
On Thu, Jan 28, 2010 at 9:34 PM, Steven D'Aprano <
Post by Steven D'Aprano
Post by Tim Roberts
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.
Out of curiosity, and completely off-topic, why has Perl 6 gone so badly?
- Super-dramatic changes to the language (some people think Python 3 is/was
radical, but it's got nothing on Perl 6)
- Complete from-scratch rewrite (c.f. Joel Spolsky's "Things You Should
Never Do")
- Ambitious implementation strategy, i.e. Parrot. It will be powerful
and useful beyond just Perl when complete, but that extra complexity comes
at a price.
=> Although why Pugs and the other implementations are likewise held up, I
have no idea. But then I'm not a Perlite (Is that the right word?).

For that matter, it remains to be seen whether the Python 3 changeover will
fare better. But I'm still pretty hopeful.
At least we have a complete reference implementation.

Cheers,
Chris
--
What we need is some sort of coordinated library porting effort. Or a
3.x-specific killer app.
http://blog.rebertia.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100128/4f8b7737/attachment.html>
alex23
2010-01-29 06:16:08 UTC
Permalink
Post by geremy condra
Post by Steven D'Aprano
Out of curiosity, and completely off-topic, why has Perl 6 gone so badly?
Too much like Perl.
I was going to suggest that it's probably due to the multitude of ways
to it could be done :)
Neil Hodgson
2010-01-29 07:22:03 UTC
Permalink
Looks to me like the problem with Perl 6 was that it was too
ambitious, wanting to fix all perceived problems with the language.
Python 3 is much more limited in scope: at its core its Python with
Unicode fixed and old junk removed.

Neil
Grant Edwards
2010-01-29 11:52:53 UTC
Permalink
Post by Neil Hodgson
Looks to me like the problem with Perl 6 was that it was too
ambitious, wanting to fix all perceived problems with the
language.
I thought Python was Perl with all the perceived problems fixed.
--
Grant
Carl Banks
2010-01-30 03:03:28 UTC
Permalink
On Jan 28, 9:34?pm, Steven D'Aprano <st... at REMOVE-THIS-
Post by Steven D'Aprano
Post by Tim Roberts
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.
Out of curiosity, and completely off-topic, why has Perl 6 gone so badly?
Because Larry Wall saw the writing on the wall that his "nice little
scripting language" was way out of its league in terms of what it was
trying to be (i.e., a real programming language suitable for building
applications), and so he bailed out and left the Perl community with
no leadership.

This is just my impression, but some of the efforts to create Perl 6
seem to be clinging to a notion that Perl has always been a good
language and are trying to ensure that it doesn't stray very far from
Perl's core principles. Problem is, Perl wasn't ever a good language
so they won't succeed. IOW, as Geremy Condra said, "it's too much
like Perl".


Carl Banks
Anssi Saari
2010-01-29 13:13:01 UTC
Permalink
Post by Daniel Fetchinson
Post by John Nagle
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.
How does your mention of one distro counter that claim? Personally,
I'd like to see a study of what version of Python ships with what
Linux distribution. Say, include the top 100 distros from
distrowatch.com? I think there may a surprising number of distros that
ship with no version of Python what so ever.
Duncan Booth
2010-01-29 13:41:38 UTC
Permalink
Post by Anssi Saari
Post by Daniel Fetchinson
Post by John Nagle
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.
How does your mention of one distro counter that claim? Personally,
I'd like to see a study of what version of Python ships with what
Linux distribution. Say, include the top 100 distros from
distrowatch.com? I think there may a surprising number of distros that
ship with no version of Python what so ever.
Is there any easier way to build that list than working through all the
distributions by hand?

Maybe someone should create a wiki page to record this.

Here's what I see in the Ubuntu packages. Python 3 seems only to be in the
universe repositories so far.

Dapper: Python 2.4.2
Hardy: Python 2.5.2
Intrepid: Python 2.5.2, 3.0~b3 (universe)
Jaunty: Python 2.6.2, 3.0.1 (universe)
Karmic: Python 2.6.4rc1, 3.1 (universe)
Lucid: Python 2.6.4, 3.1 (universe)

WTF is rc anything doing in the main repository?
--
Duncan Booth http://kupuguy.blogspot.com
Ben Finney
2010-01-29 22:29:31 UTC
Permalink
Post by Duncan Booth
Here's what I see in the Ubuntu packages. Python 3 seems only to be in the
universe repositories so far.
Dapper: Python 2.4.2
Hardy: Python 2.5.2
Intrepid: Python 2.5.2, 3.0~b3 (universe)
Jaunty: Python 2.6.2, 3.0.1 (universe)
Karmic: Python 2.6.4rc1, 3.1 (universe)
Lucid: Python 2.6.4, 3.1 (universe)
WTF is rc anything doing in the main repository?
It's to be expected if the release team process specifies announcement
messages of the form ?RELEASED: Python X.Y.Zrc2?. I have long argued,
without much traction, that the process should reserve the term
?RELEASED? for use only in reference to releases, not other things.
--
\ ?First they came for the verbs, and I said nothing, for verbing |
`\ weirds language. Then, they arrival for the nouns and I speech |
_o__) nothing, for I no verbs.? ?Peter Ellis |
Ben Finney
Benjamin Kaplan
2010-01-30 02:28:03 UTC
Permalink
Post by Ben Finney
Post by Duncan Booth
Here's what I see in the Ubuntu packages. Python 3 seems only to be in the
universe repositories so far.
Dapper: Python 2.4.2
Hardy: Python 2.5.2
Intrepid: Python 2.5.2, 3.0~b3 (universe)
Jaunty: Python 2.6.2, 3.0.1 (universe)
Karmic: Python 2.6.4rc1, 3.1 (universe)
Lucid: Python 2.6.4, 3.1 (universe)
WTF is rc anything doing in the main repository?
It's to be expected if the release team process specifies announcement
messages of the form ?RELEASED: Python X.Y.Zrc2?. I have long argued,
without much traction, that the process should reserve the term
?RELEASED? for use only in reference to releases, not other things.
Don't worry, it's not just Python. Ubuntu Hardy (IIRC) had a Firefox 3
beta in the repositories until a little while after the final release.
I don't know what's taking them so long to upgrade to the final 2.6.4
though.
Post by Ben Finney
--
?\ ? ? ?First they came for the verbs, and I said nothing, for verbing |
?`\ ? ?weirds language. Then, they arrival for the nouns and I speech |
_o__) ? ? ? ? ? ? ? ? ? ? ? ? ? nothing, for I no verbs.? ?Peter Ellis |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
Benjamin Kaplan
2010-01-29 13:54:25 UTC
Permalink
Post by Anssi Saari
Post by Daniel Fetchinson
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.
How does your mention of one distro counter that claim? Personally,
I'd like to see a study of what version of Python ships with what
Linux distribution. Say, include the top 100 distros from
distrowatch.com? I think there may a surprising number of distros that
ship with no version of Python what so ever.
--
Just from a quick look, 6 of the top 10 distros on distrowatch have
Python 2.6 including all of the top 4.
Post by Anssi Saari
http://mail.python.org/mailman/listinfo/python-list
Eric_Dexter
2010-01-29 15:48:43 UTC
Permalink
Post by Daniel Fetchinson
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. ?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
I am seeing alot of bleeding edge linux distro's with 2.5 and 2.6 I
would perfer they stayed with 2.4 or 2.5 ..
or if there is a version that I can come up with a convincing cross-
platform os.startfile I would want to use
a vmware version of that linux.
_______________________________________
http://dextracker.blogspot.com/
Blog
2010-01-30 03:33:12 UTC
Permalink
1. Python 3 is supported by major Linux distributions.
FALSE - most distros are shipping with Python 2.4, or 2.5 at best.
Where did you come up with that information? Almost all of the major
distros ship with 2.6.x - CentOS, OpenSuSe, Ubuntu, Fedora. (Debian does
ship with 2.5, but the next major release "sid' is due out in Q2)
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.
WTF? Where'd you hear about version 2.8? FRI, 2.7 is and will be THE
LAST version of the 2.x series - "the" End-Of-Life for Python 2.

At least py3k is a real product - unlike the perl 6 vaporware.

That said, I think python 2 will be the dominant player in the market
for the next couple of years.

However, there's been some momentum behind Py3k recently. Unladen
swallow is going to be merged with Py3k (not 2.x for which it was
originally developed). I hear the django guys have made huge progress in
porting the framework to Py3k (although it will be a good few months
before the code is released in the wild)
Christian Heimes
2010-01-30 17:47:17 UTC
Permalink
Post by Blog
WTF? Where'd you hear about version 2.8? FRI, 2.7 is and will be THE
LAST version of the 2.x series - "the" End-Of-Life for Python 2
Where do you get your information from? Your answer is the first that
clearly marks the end of lifetime for the 2.x series. I didn't know that
and I'm a Python core dev as well as a PSF member ... *scnr*

Christian
Blog
2010-01-30 18:08:49 UTC
Permalink
Post by Christian Heimes
Post by Blog
WTF? Where'd you hear about version 2.8? FRI, 2.7 is and will be THE
LAST version of the 2.x series - "the" End-Of-Life for Python 2
Where do you get your information from? Your answer is the first that
clearly marks the end of lifetime for the 2.x series. I didn't know that
and I'm a Python core dev as well as a PSF member ... *scnr*
Christian
Well, here's what the Python 2.7 alpha 2 (January 9th, 2010) release
note says:

"Python 2.7 is scheduled to be the last major version in the 2.x series
before it moves into 5 years of bugfix-only mode. This release contains
many of the features that were first released in Python 3.1..."

Ref: http://www.python.org/download/releases/2.7/


Here are some more resources:

"Python 2 nears end of life"

"Python 2.7, expected to be the last major version of the 2.x series of
the dynamic language, was released as a second alpha earlier month by
the Python Software Foundation, with the final release set for June.

When 2.7 is released, the 2.x line will move into five years of a bug
fix-only mode."

http://www.computerworlduk.com/technology/development/software/news/index.cfm?newsid=18331


"2.7's the end of the line. There was some discussion around the release
of 2.6 as to how far the 2.x series should go, and the conclusion which
came out of it was that 2.7 is it. Beyond this, the world is 3.x (which,
given the time it takes OS distributors to catch up -- most are still on
2.5 -- is about right with the projected time frame for most projects to
port)."

http://www.reddit.com/r/Python/comments/aoloc/python_27_alpha_2_has_been_released/


"Let?s also account for the fact that, as of this writing, Python 2.7
(scheduled for next year) is *intended* to be the End of Life release of
the Python 2.x syntax ? Python 3 being the next evolutionary step."

http://jessenoller.com/2009/12/04/pythons-moratorium-lets-think-about-this/

Of course, this isn't written in stone - there may very well be another
version after 2.7. However, at this instant, it does look like 2.7 will
be the veritable last version.

Best regards.
Martin v. Loewis
2010-01-30 18:39:24 UTC
Permalink
Post by Christian Heimes
Post by Blog
WTF? Where'd you hear about version 2.8? FRI, 2.7 is and will be THE
LAST version of the 2.x series - "the" End-Of-Life for Python 2
Where do you get your information from?
It was discussed repeatedly on python-dev, last time when the release
announcements for the 2.7 alpha releases were discussed. See

http://www.python.org/download/releases/2.7/

Regards,
Martin
Ben Finney
2010-01-30 04:06:29 UTC
Permalink
(Debian does ship with 2.5, but the next major release "sid' is due
out in Q2)
Sid is the perpetual development playground (?unstable?), never released
as a suite, but a proving ground for packages to determine their fitness
for going to the next level of testing.

The next-to-be-released suite is Squeeze (currently ?testing?), which
has Python 2.5 (the default ?python?) and Python 2.6.
--
\ ?If you define cowardice as running away at the first sign of |
`\ danger, screaming and tripping and begging for mercy, then yes, |
_o__) Mr. Brave man, I guess I'm a coward.? ?Jack Handey |
Ben Finney
Blog
2010-01-30 18:09:52 UTC
Permalink
Post by Ben Finney
(Debian does ship with 2.5, but the next major release "sid' is due
out in Q2)
Sid is the perpetual development playground (?unstable?), never released
as a suite, but a proving ground for packages to determine their fitness
for going to the next level of testing.
The next-to-be-released suite is Squeeze (currently ?testing?), which
has Python 2.5 (the default ?python?) and Python 2.6.
Oops! My bad! I actually meant Squeeze.

Thanks for catching the "typo".
Nobody
2010-01-30 16:29:02 UTC
Permalink
Arguably, Python 3 has been rejected by the market.
Arguably, Python 3 has not yet been accepted by the market.

Part of it is down to a catch-22: applications won't use Python 3 if the
libraries on which they depend don't support it, and support for Python 3
by libraries will be influenced by the perceived demand.

OTOH, it's safe to assume that there will remain areas where Python 2 is
preferred. Primarily Unix scripting, where most data is byte strings with
the encoding either unknown or irrelevant. That alone will ensure that
Python 2 is alive and well even as Python 4 is released. Even if
python.org doesn't support Python 2, it's a safe bet that e.g. ActiveState
will.
Kevin Walzer
2010-01-30 16:45:17 UTC
Permalink
Post by Nobody
Arguably, Python 3 has not yet been accepted by the market.
Part of it is down to a catch-22: applications won't use Python 3 if the
libraries on which they depend don't support it, and support for Python 3
by libraries will be influenced by the perceived demand.
This is part of my reason for not yet moving to Python 3--several
libraries that I will need do not currently support Python 3.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Anssi Saari
2010-02-01 23:08:39 UTC
Permalink
Post by Blog
Where did you come up with that information? Almost all of the major
distros ship with 2.6.x - CentOS, OpenSuSe, Ubuntu, Fedora. (Debian
does ship with 2.5, but the next major release "sid' is due out in Q2)
I don't see Python 2.6 in my CentOS 5.4 installation. All I see is
2.4. Same as RHEL and I'd say that's a fairly major distribution too.
Edward A. Falk
2010-01-27 23:50:19 UTC
Permalink
In article <mailman.1470.1264588330.28905.python-list at python.org>,
Post by Daniel Fetchinson
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
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.
Post by Daniel Fetchinson
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, falk at despams.r.us.com
http://thespamdiaries.blogspot.com/
Loading...