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
This is actually misleading by itself, as the first statement is not a
function call in Py2:
Python 2.6.4 (r264:75706, Dec 7 2009, 18:43:55)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print(1,2)
(1, 2)
It can, however, be made a function call through a future import in 2.6:
>>> from __future__ import print_function
>>> print(1,2)
1 2
Stefan
Well, I see two false or misleading claims just above - namely that
the two claims above are false or misleading. They tell just half of
the story, and that half is indeed easy. A Python 3 program can be
unchanged (in the case of print) or with only trivial modifications
(in the case of integer division) be made to run on Python 2.6. The
other way around this is _not_ the case. To say that two things are
compatible if one can be used for the other, but the other not for the
first, is false or misleading.
--
André Engels, andre...@gmail.com
Okay, so we agree that as long as print and integer division is
concerned, a program can easily be written that runs on both 2.6 and
3.x.
My statements are exactly this, so I don't understand why you disagree.
> The other way around this is _not_ the case.
What do you mean?
> To say that two things are
> compatible if one can be used for the other, but the other not for the
> first, is false or misleading.
I'm not sure what you mean here. Maybe I didn't make myself clear
enough, but what I mean is this: as long as print and integer division
is concerned, it is trivial to write code that runs on both 2.6 and
3.x. Hence if someone wants to highlight incompatibility (which surely
exists) between 2.6 and 3.x he/she has to look elsewhere.
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
if print:
print('Hello')
---
def myPrint(*args):
for arg in args:
sys.stdout.write(str(arg))
print = myPrint
JM
from __future__ import print_function
if print:
print('Hello')
def myPrint(*args):
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/
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
> 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
CentOS: python26-2.6.4-1.ius.parallel.el5
openSUSE: python-2.6.2-6.3.i586, python3-3.1-3.3.i586
Darn, those pesky facts.
> 2. Python 3 is supported by multiple Python implementations.
> FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow,
> PyPy, and Jython have all stayed with 2.x versions of Python.
And of all Python development what percentage takes place on all those
combined? 2%? Maybe.
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.
> Myths about Python 3:
>
> 1. Python 3 is supported by major Linux distributions.
>
> FALSE - most distros are shipping with Python 2.4, or 2.5 at
> best.
There's a big difference between “What list of versions of Python does
<fooOS> ship with?” versus “Which one version of Python does <fooOS> use
for its implementation of ‘python’?”. I think the latter is the more
pertinent question.
Do you have evidence to back up a claim (not that I'm saying you have
necessarily made the claim; it's not clear from what you wrote) that
most operating systems use Python 2.4 as their implementation of
‘python’?
--
\ “Anyone who believes exponential growth can go on forever in a |
`\ finite world is either a madman or an economist.” —Kenneth |
_o__) Boulding |
Ben Finney
> 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
You are wrong. Modern versions of Debian / Ubuntu are using Python 2.6.
My Ubuntu box has python3.0, too.
> 2. Python 3 is supported by multiple Python implementations.
>
> FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow,
> PyPy, and Jython have all stayed with 2.x versions of Python.
You are wrong again. We have an active discussion on the Python
developer mailinglist to integrate Unladen Swallow into py3k, see
http://jessenoller.com/2010/01/06/unladen-swallow-python-3s-best-feature/
. The other implementations have been planing Python 3.x support for
more than a year.
>
> 3. Python 3 is supported by most 3rd party Python packages.
>
> FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.
Python 3.x has builtin support for several aspects of OpenSSL. Other
important projects like Cython, lxml, some Postgres DBAs, Django,
mod_wsgi and many more have been ported to Python 3.x for more than a
year. In fact Graham has helped us to identify several issues in 3.0
beta while he was porting mod_wsgi to Python 3.0.
(Personally I neither see MySQL as mission critical nor as a powerful
RDBMS. Just try to combine foreign keys with triggers and you'll see
what I'm talking about. *scnr*)
Christian
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
> John Nagle wrote:
> > 1. Python 3 is supported by major Linux distributions.
> >
> > FALSE - most distros are shipping with Python 2.4, or 2.5 at best.
>
> You are wrong. Modern versions of Debian / Ubuntu are using Python
> 2.6.
Only if by “modern” you mean “not released yet”.
The latest stable Debian (Debian 5.0, Lenny) has only Python 2.4 and
Python 2.5. It does not have Python 2.6 at all, and until this month
Python 2.6 was not even in the in-development suite of Debian.
Fortunately, Debian Squeeze now finally has added Python 2.6 (though
currently ‘python’ still uses Python 2.5). But Squeeze is currently a
long way from being released.
Python 3 is in the play-pen of Debian “unstable”, but only arrived this
week. It's even further from being released; it has to pass the filter
from “unstable” to “testing” before it gets consideration for that.
So I think your statement above is at least a mischaracterisation of the
truth.
--
\ “As scarce as truth is, the supply has always been in excess of |
`\ the demand.” —Josh Billings |
_o__) |
Ben Finney
PostgreSQL support is available for Python3.
Just switch to using a real database and one of you problems is
solved. :)
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
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
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
> 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
I said myths, not facts! :)
s/Myths/Facts/
> 1. Python 3 is supported by major Linux distributions.
>
> FALSE - most distros are shipping with Python 2.4, or 2.5 at best.
This latter statement is false, Fedora 11 and 12 come with python 2.6.
> 2. Python 3 is supported by multiple Python implementations.
>
> FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow,
> PyPy, and Jython have all stayed with 2.x versions of Python.
This latter statement is false, unladen swallow is currently targeting
3.x and may even be merged into cpython 3.x.
> 3. Python 3 is supported by most 3rd party Python packages.
>
> FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.
s/most/my favorite/
Actually, tons of 3rd party packages are already ported, postgres and
django are just 2 examples, the next release of PIL will be another.
> Arguably, Python 3 has been rejected by the market. Instead, there's
> now Python 2.6, Python 2.7, and Python 2.8. Python 3 has turned into
> a debacle like Perl 6, now 10 years old.
These are the kinds of myths I had in mind when starting the thread.
All sorts of BS is kept circulating without any facts to back up the
claims. Actually, in this thread tons of rebuttals can be found to
your statements but I doubt you will change your mind :) Hopefully
others reading all of this will at least see what is BS and what is
the actual situation about python 3.
FWIW, more information on Fedora python 3 status here:
https://fedoraproject.org/wiki/Features/Python3F13
[snip]
> Give the package maintainers time to update. There were some pretty
> big changes to the C API. Most of the major 3rd party packages like
> numpy and MySQLdb have already commited to having a Python 3 version.
> They just haven't gotten them out yet.
I'll take this opportunity to make a shameless plug for my 2to3c tool:
http://dmalcolm.livejournal.com/3935.html
which takes some of the grunt work out of taking C code and making it
compilable against both 2 and 3. (it will still require a human to do
some of the work, alas).
Hope this is helpful
Dave
Yes, but does print as a statement work?
Your argument is that python 2.x code can be ported to 3.x and still
run under 2.6 if you're careful about how you do the port. That's
not the same as saying they're compatible.
>2. Integer division creates incompatibility between 2.x and 3.x!
Same as above. Saying you can make it work by rewriting your code
is not the same as saying that it works.
If they'd wanted wide adoption of python 3, they should have made it
as compatible as possible with python 2 code. If they dropped the
print statement, then they did not do so.
--
-Ed Falk, fa...@despams.r.us.com
http://thespamdiaries.blogspot.com/
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.
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~
> Daniel Fetchinson wrote:
>> Hi folks,
>>
>> I was going to write this post for a while because all sorts of myths
>> periodically come up on this list about python 3. I don't think the
>> posters mean to spread false information on purpose, they simply are
>> not aware of the facts.
>>
>> My list is surely incomplete, please feel free to post your favorite
>> misconception about python 3 that people periodically state, claim or
>> ask about.
>
> Myths about Python 3:
>
> 1. Python 3 is supported by major Linux distributions.
> 2. Python 3 is supported by multiple Python implementations.
> 3. Python 3 is supported by most 3rd party Python packages.
A myth actually needs to be believed by some sector of the population,
even if a small one. (Isolated nut cases don't count.) Star Wars is not a
myth, because nobody -- not even those wacky people who put down "Jedi"
as their religion on census forms -- actually believes it is a
documentary.
I've never heard anyone claiming any of those three "myths". I conclude
that you just made them up, that they are fictional claims rather than
genuine myths mistakenly believed by some people. So, in that spirit,
here are three more for your collection. Perhaps you could start a list
on a website somewhere.
4. Python 3 will make you irresistible to women.
FALSE - Python 3 coders are no more likely to get a date than any
other programmer.
5. Python 3 programs cannot be buggy, no matter how poorly you code.
FALSE - programs written in Python 3 can contain bugs.
6. The code for Python 3 was handed down to Guido from the Heavens,
carved into stone tablets by the Gods themselves.
FALSE - Python 3 was designed and written by fallible human beings,
and consequently there is no guarantee that it will be perfect in
all ways for all purposes.
> That's the reality, Python 3 fanboys.
Speaks for itself.
--
Steven
I should have said, "If anything...".
Carl Banks
That is heresy. The direction was up, not down.
> 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
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.
SPLITTER!!!
--
Steven
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
> 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
> 2. Python 3 is supported by multiple Python implementations.
>
> FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow,
> PyPy, and Jython have all stayed with 2.x versions of Python.
>
Your selective information here is particularly partial to your case. I
have spoken with developers from IronPython and Jython, and both teams
are committed to eventual support of 3.x.
> 3. Python 3 is supported by most 3rd party Python packages.
>
> FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.
>
I would argue it's up to Python to support those facilities rather than
the other way round.
> Arguably, Python 3 has been rejected by the market. Instead, there's
> now Python 2.6, Python 2.7, and Python 2.8. Python 3 has turned into
> a debacle like Perl 6, now 10 years old.
>
> That's the reality, Python 3 fanboys.
>
Kindly confine your debate to the facts and keep the snide remarks to
yourself. Like it or not Python 3 is the future, and unladen swallow's
recent announcement that they would target only Python 3 represented a
ground-breaking advance for the language.
Happily my Python 2.x interpreters all continue to work just as they
have since they were installed. If you have to stretch as far as Perl 6
for an analogy then you have clearly stretched a little too far. The
situations are not even closely comparable, and I defy you to argue
otherwise.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/
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?
This statement was to counter the 'myth' that US was only targeted at
2.x when the current situation is quite the opposite.
>> I would not be completely shocked if it happens in 3.2.
I was initially rather dubious about the idea. I based the above
on the team's acceptance of and response to reasonable requirements.
In particular, several people said that the speed/space traceoff
should be optional, and that compilation 'without llvm' should really
be without, not just with llvm present but disabled. Instead of arguing,
Colin went ahead and patched the build process to make it be this way.
> Why do I feel like there's less of an onus on Unladen Swallow to
> _actually prove itself in substantial real world usage_ before
> integration into CPython than there is on even the smallest of modules
> for inclusion in the standard library?
I have no idea. It will have to improve its speedup more before
adoption. I will not be surprised if that happens.
> Are we really expected to just ditch everything we know about
> CPython's performance characteristics just for some questionable and
> possibly uneven gains?
>
> I've been a big supporter of Py3 from the beginning, but this repeated
> claim of US becoming the mainline interpreter for 3.x
US is not a new or separate interpreter. It will be an optional jit
replacement for one component of CPython, the eval loop. All the code
for builting functions, types, and modules will be untouched, as will
their big O performance characteristics.
> pretty much kills dead a lot of my interest.
If you can still have a binary free of the traceoff, why would you care?
> What am I not seeing amidst the high
> memory usage and variable performance results of US's _custom-made_
> benchmarks? Doesn't that fact alone worry anyone else? Or that LLVM is
> listed as only having "partial support" with non-Cygwin x86 Windows?
They claim they have pretty well fixed that. They know that complete
Windows support, including 64 bit versions, is a necessity.
Terry Jan Reedy
From an implementors point of view, it's actually quite the opposite. Most
syntax features of Python 3 can be easily implemented on top of an existing
Py2 Implementation (we have most of them in Cython already, and I really
found them fun to write), and the shifting-around in the standard library
can hardly be called non-trivial. All the hard work that went into the
design of CPython 3.x (and into its test suite) now makes it easy to just
steal from what's there already.
The amount of work that the Jython project put into catching up from 2.1 to
2.5/6 (new style classes! generators!) is really humongous compared to the
adaptations that an implementation needs to do to support Python 3 code. I
have great respect for the Jython project for what they achieved in the
last couple of years. (I also have great respect for the IronPython project
for fighting the One Microsoft Way into opening up, but that's a different
kind of business.)
If there was enough interest from the respective core developers, I
wouldn't be surprised if we had more than one 'mostly compatible'
alternative Python 3 implementation in a couple of months. But it's the
obvious vicious circle business. As long as there aren't enough important
users of Py3, alternative implementations won't have enough incentives to
refocus their scarce developer time. Going for 2.6/7 first means that most
of the Py3 work gets done anyway, so it'll be even easier then. That makes
2.6->2.7->3.2/3 the most natural implementation path. (And that, again,
makes it a *really* good decision that 2.7 will be the last 2.x release line.)
>> 3. Python 3 is supported by most 3rd party Python packages.
>>
>> FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc.
>>
>> Arguably, Python 3 has been rejected by the market. Instead, there's
>> now Python 2.6, Python 2.7, and Python 2.8. Python 3 has turned into
>> a debacle like Perl 6, now 10 years old.
>
> Give the package maintainers time to update. There were some pretty
> big changes to the C API. Most of the major 3rd party packages like
> numpy and MySQLdb have already commited to having a Python 3 version.
> They just haven't gotten them out yet.
I second that. NumPy has already announced that they'll rewrite some of
their code in Cython to make it more maintainable and portable (and to
simplify the port to Py3, I guess). Other projects will equally well find
their ways to get their code ready. It's just a matter of time. I think
there's enough pressure on the maintainers by now (both from users and from
personal pride) to consider their packages tainted if they aren't portable
enough to run on all major (C)Python versions (and Py3.1 certainly is one
of them), even if they don't use them themselves. That appears to be an
impressively good incentive.
Stefan
'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
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.
But as Steven points out, the difference from 2.2 to 2.6 is roughly the
same as 2.6 to 3.1. Python has never before had such a large difference
from one release to the next, and I think few people try to support
serious apps on the full range from 2.2 to 2.6. Moreover, the task of
using a single codebase without 2to3 is much easier in 1.4 through 2.6.
Admittedly, it wouldn't be much fun to write 1.4 code these days without
all the neat features that have been added, but you can't argue that it's
hard.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
import antigravity
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.
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.
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.
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.
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
>> 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
What?!? Drat!!! Guess I'll have to learn Lisp... ;)
~Ethan~
> Le Thu, 28 Jan 2010 00:19:24 +0000, Steven D'Aprano a écrit :
> > 4. Python 3 will make you irresistible to women.
> >
> > FALSE - Python 3 coders are no more likely to get a date than
> > any other programmer.
>
> They spend less time coding, so they /can/ get more "dates" (what a
> strange English word) :-)
Perhaps Steven could tell you about a lovely Australian meaning for the
word “date”.
--
\ “Even if the voices in my head are not real, they have pretty |
`\ good ideas.” —anonymous |
_o__) |
Ben Finney
Irresisible? Ha! The chicks will think you have a harelip.
>
> ~Ethan~
Learn to say this fast, you'll impress the hell out of them:
Chaps with chapped lips lisp.
> Antoine Pitrou <soli...@pitrou.net> writes:
>
>> Le Thu, 28 Jan 2010 00:19:24 +0000, Steven D'Aprano a écrit :
>> > 4. Python 3 will make you irresistible to women.
>> >
>> > FALSE - Python 3 coders are no more likely to get a date than any
>> > other programmer.
>>
>> They spend less time coding, so they /can/ get more "dates" (what a
>> strange English word) :-)
>
> Perhaps Steven could tell you about a lovely Australian meaning for the
> word “date”.
This is a family list, so perhaps I shouldn't. :)
In Australia slang, "date" is short for "date hole", which is the part of
the anatomy which is also known as "the [one] brown eye". In parts of the
US, it is also known as the "corn hole", and in Cockney rhyming slang it
is a jam role.
I trust I don't need to be any more explicit...
--
Steven
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
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
Not so much 'myth' as 'outdated information', they were very clear
that 2.x was the initial target.
> In particular, several people said that the speed/space traceoff
> should be optional, and that compilation 'without llvm' should really
> be without, not just with llvm present but disabled. Instead of arguing,
> Colin went ahead and patched the build process to make it be this way.
Ah, that's excellent. The impression being given off is that it's a
total replacement.
> I have no idea. It will have to improve its speedup more before
> adoption. I will not be surprised if that happens.
It's not so much about being surprised or not, it's wanting actual
evidence and not just claims, and moreso _extensive real world usage_
before it's integrated. This seems far more intimate a change than
adding a module to the stdlib, I expect it to have at _least_ the
evaluation time & vague consensus of approval expected of those.
> US is not a new or separate interpreter. It will be an optional jit
> replacement for one component of CPython, the eval loop. All the code
> for builting functions, types, and modules will be untouched, as will
> their big O performance characteristics.
As long as there aren't any related decreases in performance in other
areas, I'll be happy.
> If you can still have a binary free of the traceoff, why would you care?
Well, I didn't know I could, so now I don't quite as much :)
> They claim they have pretty well fixed that. They know that complete
> Windows support, including 64 bit versions, is a necessity.
Maybe I'll be a lot more convinced after the Q4 report.
The 'incomplete' Windows support may not be as big an issue as I
thought, it seems to refer to a lack of support for older Windows
versions rather than an incomplete implementation on the supported
ones.
Cheers, Terry, this addressed a lot of my concerns, although I'm still
keen to see more facts & real-world usage over custom-crafted
benchmarks and enthusiastic claims.
Although I happen to be one of the folks who are reluctant to switch to
Python 3, I have to say that this comparison is entirely unfair. Python 3
exists in the wild. It has been released, and has even had a couple of
updates. Eventually, it will prevail. Resistance is futile, you WILL be
assimilated.
Perl 6, on the other hand, is still fantasyware a decade after its
announcement. It is, for the most part, THE canonical example of the wrong
way to conduct a development effort.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
> 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
I was going to suggest that it's probably due to the multitude of ways
to it could be done :)
Neil
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
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).
> 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
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.
> 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.
> 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
> 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
> 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
Ah, I suppose it explains the strange ASCII art drawing in your signature
then?
(Here)
|
|
v
> '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.
>> 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
Just from a quick look, 6 of the top 10 distros on distrowatch have
Python 2.6 including all of the top 4.
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/
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
> 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
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.
> --
> \ “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
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
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)
There's a prime example - it's called Windows Vista! ;)
> (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
> 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.
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
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.
Oops! My bad! I actually meant Squeeze.
Thanks for catching the "typo".
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
> 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.