Python 2.7.7 released(mail.python.org)
mail.python.org
Python 2.7.7 released
https://mail.python.org/pipermail/python-dev/2014-June/134694.html
3 comments
huh, as a developer thinking of starting Python, is python 2.X still worthwhile to start with? The python.org even has a subsection for 'starting with 2 or 3', and of course they promote 3, but recent posts have made me think twice about starting with the newest.
Python 3 is increasingly the better choice. The major exception is if you need a library which hasn't been ported yet but that list continues to shrink:
http://python3wos.appspot.com/
The good news is that it's increasingly easy to write programs which run on both using newer idioms via __future__ backports, which is often both future proof and a way to write better code using newer language features which many people miss out on due to habit and old tutorials.
Lennart Regebro has a wonderful guide covering the changes and how to deal with them as painlessly as possible:
http://python3porting.com/differences.html
http://python3wos.appspot.com/
The good news is that it's increasingly easy to write programs which run on both using newer idioms via __future__ backports, which is often both future proof and a way to write better code using newer language features which many people miss out on due to habit and old tutorials.
Lennart Regebro has a wonderful guide covering the changes and how to deal with them as painlessly as possible:
http://python3porting.com/differences.html
The biggest problem is many of the best tutorials are written in Python 2.7. Udacity's Intro to CS and Learn Python the Hard Way come to mind.
The python.org tutorial[0] is available in both 2 & 3, and is a perfectly great, but often overlooked, resource for learning the language.
[0]: https://docs.python.org/3/tutorial/
[0]: https://docs.python.org/3/tutorial/
It is a great tutorial for someone with some programming experience but for complete beginners it's not adequate.
This is sadly true, although as Lennart's guide makes it clear many of those can trivially be updated to run on both. I'm hoping the next year leads to a lot of the simple updates happening so tutorial code can run against both — with `from __future__ import absolute_import, division, print_function, unicode_literals` quite a few programs can easily be single-source using only stock Python 2.7 / 3.4 without needing to introduce something like six.
The code in Learn Python the Hard Way is all really easy to port to Python 3 since it's written for new programmers, that said. New programmers won't know that.
Udacity is stuck with 2.7 until GAE supports Python 3.
Thanks for that link. As of tonight, I'm committed to writing version independent code.
You definitely want 2.7. The best learning material is in 2.7 (LPTHW), all libraries support 2.x but not 3.x, no PyPy that's not in beta, performance on 3.x is less than 2.7 and all online hosts are on 2.7 or earlier (Azure, Google App Engine, etc). Most of the resources available online for help are 2.x.
Not to mention the unicode implementation is broken. I was just talking to a Russian user (someone you'd assume would want unicode by default), and Python3 not operating on bytes by default is a mess. He can't move to Python3 due to how unicode is implemented.
print sys.getdefaultencoding() # ascii
print locale.getpreferredencoding() # cp1251
print sys.stdout.encoding # cp866
print sys.getfilesystemencoding() # mbcs
#~ print u"кодировочка!"
#~ print u"кодировочка!".encode('cp866')
#~ print unicode(u"кодировочка!", 'cp1251')
#~ os.rename ('b', u'б')
In most things in life, you'd always want the 'latest version', it would be a no-brainer. I wouldn't even bet on the transition to Python3 succeeding until it has- it's been 6 1/2 years already.
Use 2.7 and then move to 3.x when and if it ever makes sense. It won't be hard at all to switch as a user, that's not the problem.
Not to mention the unicode implementation is broken. I was just talking to a Russian user (someone you'd assume would want unicode by default), and Python3 not operating on bytes by default is a mess. He can't move to Python3 due to how unicode is implemented.
print sys.getdefaultencoding() # ascii
print locale.getpreferredencoding() # cp1251
print sys.stdout.encoding # cp866
print sys.getfilesystemencoding() # mbcs
#~ print u"кодировочка!"
#~ print u"кодировочка!".encode('cp866')
#~ print unicode(u"кодировочка!", 'cp1251')
#~ os.rename ('b', u'б')
In most things in life, you'd always want the 'latest version', it would be a no-brainer. I wouldn't even bet on the transition to Python3 succeeding until it has- it's been 6 1/2 years already.
Use 2.7 and then move to 3.x when and if it ever makes sense. It won't be hard at all to switch as a user, that's not the problem.
Actually, Unicode handling is broken on Python 2, and works just fine on Python 3. I'm also a Russian user :)
Your code doesn't make any sense. Care to comment on what it means?
Guido didn't do us any favors with his migration strategy, but Python 3.4 is a substantially better and more modern language, so I would suggest developing on it (it's supported out of the box on Ubuntu 14.04 LTS, for example). It's true that app platform providers have not caught up yet, though.
Your code doesn't make any sense. Care to comment on what it means?
Guido didn't do us any favors with his migration strategy, but Python 3.4 is a substantially better and more modern language, so I would suggest developing on it (it's supported out of the box on Ubuntu 14.04 LTS, for example). It's true that app platform providers have not caught up yet, though.
Yeah. I moved all code dealing with Unicode (in particular, parsing iTunes track names) to Python 3. That was the one part of the language that worked well for me- instead of utf8 codec hell, things just worked.
> Not to mention the unicode implementation is broken.
Can you provide more details? The one thing that python3 did well is actually fixing the unicode/str mixup.
You posted some lines of code, but didn't tell exactly what's wrong with it.
> Python3 not operating on bytes by default is a mess
Why not just use the b'' prefix then and be explicit?
> can't move to Python3 due to how unicode is implemented
I'd like to see the bugs he raised against python 3 regarding this. There should be no difference in what you can and cannot do using python 2/3. I don't want to call BS on this, but... please provide some specific issues if you're claiming py3 is not usable.
Can you provide more details? The one thing that python3 did well is actually fixing the unicode/str mixup.
You posted some lines of code, but didn't tell exactly what's wrong with it.
> Python3 not operating on bytes by default is a mess
Why not just use the b'' prefix then and be explicit?
> can't move to Python3 due to how unicode is implemented
I'd like to see the bugs he raised against python 3 regarding this. There should be no difference in what you can and cannot do using python 2/3. I don't want to call BS on this, but... please provide some specific issues if you're claiming py3 is not usable.
> and Python3 not operating on bytes by default is a mess.
I'm not arguing that it's not, but I don't how your examples support your point. Would you please explain how your examples show that "strings are unicode" is broken on Python 3?
FWIW, here's what I get:
Python 2:
I'm not arguing that it's not, but I don't how your examples support your point. Would you please explain how your examples show that "strings are unicode" is broken on Python 3?
FWIW, here's what I get:
Python 2:
>>> import sys, locale
>>> print(sys.getdefaultencoding())
ascii
>>> print(locale.getpreferredencoding())
UTF-8
>>> print(sys.stdout.encoding)
UTF-8
>>> print(sys.getfilesystemencoding())
utf-8
>>> print(sys.getdefaultencoding())
utf-8cp866 and cp1251? Something is seriously wrong there. This Russian user's OS is using two different obsolete 1-byte encodings, and claiming not to know anything about UTF-8.
Is he running Python in, say, a Command Prompt window that's maintaining compatibility with a Russian-localized version of MS-DOS?
I can see how he can't move to Python 3, because Unicode support in his environment is basically impossible. That's a deeper problem than just Python. If he's been writing Python 2 code that deals with Russian text, it's probably producing mojibake when run on any machine but his own!
Is he running Python in, say, a Command Prompt window that's maintaining compatibility with a Russian-localized version of MS-DOS?
I can see how he can't move to Python 3, because Unicode support in his environment is basically impossible. That's a deeper problem than just Python. If he's been writing Python 2 code that deals with Russian text, it's probably producing mojibake when run on any machine but his own!
I was going to argue that the vastly improved Unicode support in Py3k would be reason enough to use it. And this is coming from a person who is bilingual with both languages using different, non-7bit-ascii alphabets.
Start with 3. Most of the complaints you see on Hacker News are from people who have a large existing codebase in 2.x that they'd need to migrate over, or who need to use an esoteric library that hasn't been ported over. It will probably never make sense for these people to migrate; they have a large fixed cost to update their software, and the benefits won't outweigh them for a long time. You don't have that cost, so you might as well enjoy the benefits.
While there are significant differences between 2 and 3, mostly they aren't that big of a deal in terms of learning the language. There's no reason you can't learn both simultaneously, and its not hard to learn one from knowing the other, so its probably less important than you might think which you choose to learn first.
If you are going to do new greenfield development with no particular expectation of being tied to 2, 3 is probably better, But there's still some things you might wish to leverage that might make knowing 2, and how it differs from 3, useful.
If you are going to do new greenfield development with no particular expectation of being tied to 2, 3 is probably better, But there's still some things you might wish to leverage that might make knowing 2, and how it differs from 3, useful.
3.x is a much better language to learn with (the difference between strings and bytes is really important, and somewhat obscured in 2.x). If you need some 2.x-only library then use 2.x, but otherwise go with 3.x. I wouldn't put a lot of stock in the angry blog posts we've had lately.
Start with 3.
The libraries are not that big of a problem, and since you plan to start with it, chances are you probably won't even have a need to use these libraries anyway (you don't have any existing codebase that relies on 2.x or these libraries).
The language is much cleaner in version 3 and from what I read and my personal experience it is much easier to make code written for version 3 work with 2.7 than the other way.
The libraries are not that big of a problem, and since you plan to start with it, chances are you probably won't even have a need to use these libraries anyway (you don't have any existing codebase that relies on 2.x or these libraries).
The language is much cleaner in version 3 and from what I read and my personal experience it is much easier to make code written for version 3 work with 2.7 than the other way.
I've just (1 hour ago) updated my Python 3 library [1] to support Python 2.7 as well. All I needed to do was pass it through the awkwardduet, the 3to2 fork, and everything just worked.
Writing in Python 3 feels way cleaner though. The objects super calls that didn't need to know their current class was great to use.
[1] https://pypi.python.org/pypi/PyLaTeX
Writing in Python 3 feels way cleaner though. The objects super calls that didn't need to know their current class was great to use.
[1] https://pypi.python.org/pypi/PyLaTeX
They are both the same language, and I'd argue the differences are really minor/unimportant when it comes to learning Python. This whole 2 vs 3 has been blown out of proportion by the community.
The choice only needs to be done when you know you will use a third party library that only supports Python 2. Some simple libraries can even be ported automatically using the 2to3 tool.
The choice only needs to be done when you know you will use a third party library that only supports Python 2. Some simple libraries can even be ported automatically using the 2to3 tool.
What libraries are you using? Check their status. Some libraries are not ported to 3.X and many that have been ported are probably not as well tested as their 2.x versions.
If you plan to just use pure Python (standard library), then give 3 a try.
If you plan to just use pure Python (standard library), then give 3 a try.
Totally agreed. Think about you're going to develop, check if the libraries are there, and if they are, go 3 and don't look back. I see no point in starting from 0 and working with what is already a legacy language - unless there's a hard requirement tying you to Python 2.
I too asked myself when starting Python about 2 months ago. I initially started with Python 3.4, then I started experimenting with some code recipes on ActiveState. Then i realized i would need v 2.7 for most of what I was interested in website analysis - Twisted.
So now I am torn between the 2, these days because my coding is simple all I have to look for is if I need or don't need a '()' in my print statements. I am glad i am not at the level where I need to worry about how 'bytes' are handled.
I do hope this 3 vs. 2 thing gets resolved quickly, I really like the simplicity of Python but for beginners this battle is off-putting
Survival of the fittest?
Survival of the fittest?
As a happy Twisted user, my advice is to just stick with Python 2 and enjoy it. If you end up having to deal with Unicode, then do a bit of research on what to watch out for. If Twisted is up your application's alley, it's worth every bit of effort to learn it and use it. I started learning it in '03 and the investment has been repaid many times over.
I don't know much about it, but I was under the impression that the new asyncio library in Py3 included callback support -- though it may not have everything you want that's in Twisted.
Twisted is a huge, amazingly capable networking framework that goes way, way beyond just providing async. I say that as a frequent user of it, and I'm not moving to Python 3 until Twisted has.
[deleted]
It's trivial to upgrade from 2.7 to 3, you can pick based on the availability of the libraries you plan to use. If all you need has been ported to 3 just go with it, otherwise you can use 2.7 and make your code future-proof by importing some things from __future__ (the print function, unicode literals, etc.).
If I were just starting out, I'd go with whichever version the boasted the most examples on Stack Overflow. While more and more are written in 3.x or include both, for now it will be much easier to learn 2.x.
I agree with those recent posts, and I have lots of 2.X code. But you really ought to consider the broader implications if you are planning to invest a lot of time.
Default to version 3. However you need to check these 2 things:
1. Are the libraries you need available in python 3. (Most are, but there are exceptions).
2. What are you deploying on. There's still a lot of older RHEL/CentOS series servers in production. At best the ops team will say "no" when you tell them to install python 3.
1. Are the libraries you need available in python 3. (Most are, but there are exceptions).
2. What are you deploying on. There's still a lot of older RHEL/CentOS series servers in production. At best the ops team will say "no" when you tell them to install python 3.
> There's still a lot of older RHEL/CentOS series servers in production. At best the ops team will say "no" when you tell them to install python 3.
And then you tell them that it's better to not build against the system python and ask them again to install another version.
And then you tell them that it's better to not build against the system python and ask them again to install another version.
Presumably they're already installing app-specific pythons via virtualenv? As you indicate, system python is a bad idea. They might still prefer python 2.7?
A better version of the first question is, are the libraries you need, and will ever need in the lifetime of this application, available in python 3? If you can't predict the answer to this, it's risky to go with Python 3.
This seems to presume that no libraries that you might ever need are exclusively Python 3 -- if they are, then both choices have risks. Sure, there's probably more existing Python 2-only libraries than Python 3-only ones, but if the challenge is to predict not only the libraries you need now, but the libraries you "will ever need in the lifetime of this application"...
About 2: https://www.softwarecollections.org/en/
Now RHEL and CentOS have a solution for python 3.3
Now RHEL and CentOS have a solution for python 3.3
[deleted]
For us, it's only if Autodesk (and other applications that bundle python) are putting python 3 in their packages...
Oh, and our best python coders do not like 3 - I'm more of a lua/c person myself so for me only the first point is important.
Oh, and our best python coders do not like 3 - I'm more of a lua/c person myself so for me only the first point is important.
I'd be interested to know what they don't like about Python 3.
Most obviously - things that would no longer work in 3, that used to work in 2 - if that was not a problem, then it would've been an issue to switch (and the performance is not worse than 2).
But I guess it's not that easy. Also the "C" api must be backward-compatible.
But I guess it's not that easy. Also the "C" api must be backward-compatible.
If You skim through Armin Ronacher blog [1] and you will find out pretty soon :) Also there is a Q&A for Python 2 vs 3 by Nick Coghlan. [2]
Basically Python 3 makes it much-much harder working with legacy POSIX system and web frameworks where you need to do a bunch of unicode <--> bytes encoding dance seemingly unnecessary.
[1]: http://lucumr.pocoo.org/
[2]: http://python-notes.curiousefficiency.org/en/latest/python3/...
Basically Python 3 makes it much-much harder working with legacy POSIX system and web frameworks where you need to do a bunch of unicode <--> bytes encoding dance seemingly unnecessary.
[1]: http://lucumr.pocoo.org/
[2]: http://python-notes.curiousefficiency.org/en/latest/python3/...
[deleted](1)