10 ms·

Python 3.2 Released

142 points by mattyb 16y ago

steve918 16y ago
Sweet, now when is WSGI going to have 3.0 compatibility worked out so that it's reasonable to start using it?
- henryprecheur 16y ago
  We still need to wait for WSGI based frameworks and wrappers like Django, werkzeug, WebOb, etc. to be ported. It shouldn't be too long though. I'd bet that in 6 months 1 or 2 projects will already be functional.
xiongchiamiov 16y ago
The concurrent.futures module looks interesting: http://docs.python.org/dev/whatsnew/3.2.html#pep-3148-the-concurrent-futures-module http://docs.python.org/dev/whatsnew/3.2.html#pep-3148-the-co... I don't have much experience in that area, so I can't judge if it's as cool as I think it is. Will anyone help me out? The ability to safely convert string representations of data structures into the structures themselves seems pretty sweet, too: http://docs.python.org/dev/whatsnew/3.2.html#ast http://docs.python.org/dev/whatsnew/3.2.html#ast
- mattgreenrocks 16y ago
  > I don't have much experience in that area, so I can't judge if it's as cool as I think it is. Will anyone help me out? It is quite cool. Strictly speaking, it doesn't have to be in standard library, but Python has always had a batteries-included mentality anyway. Besides, it offers a more sane way to parallelize execution than mutexes, and that mentality should be encouraged. The entire java.util.concurrent.* library is quite good, actually. No shame in porting it.
kbatten 16y ago
If I could easily update python so that yum still worked fine on centos I would definitely start using python3. As it is I'm still stuck with python2.4 for a majority of the stuff I write.
- Maascamp 16y ago
  You can always use virtualenv and whatever version of Python you want.
- lmz 16y ago
  The IUS repository http://iuscommunity.org/ http://iuscommunity.org/ has Python 3 (and Python 2.6) packages that install side by side.
- njharman 16y ago
  You can always install other versions of Python. I have never used the distro's version of Python. I have always built my preferred version from source. It's trivial.
jefe78 16y ago
This is both wonderful and disappointing. We're still pretty locked into 2.6. I'd love to move to 3.2 but it would break EVERYTHING!!!!(! added for emphasis!) Maybe in ~10 years, everyone will be using 3.2, I know I can't wait! :D
- wisty 16y ago
  Remember the break from Numeric to numpy / scipy.core? Matplotlib managed to port OK, which was not small feat. The fact that you could do lots of try/excepts helped: try: import Numeric as np newaxis = np.NewAxis ... else: import numpy as np newaxis = np.newaxis I think that was about 10 years ago. It took ~5 years to gain acceptance. Python 3 is < 2.5 years old (3.0 final was Dec, 2008), so it's not doing that badly. The big problem seems to be whether both versions can run off the same source base, even with some voodoo (i.e. defining print functions, etc).
- dochtman 16y ago
  Move to 2.7 first, which should be fairly easy. From there, moving on to 3.x is much easier.
  - logic 16y ago
    Agreed. Once I made the mental decision to stop supporting Python < 2.7, I ended up with at least one code base that runs under both 2.7 and 3.2. Switching to print() ("from __future__ import print_function"), basing error objects on Exception instead of StandardError, and wrapping loops over .items() or .keys() with list() were the only significant changes, and all of the above are available in 2.7. Runtime for a typical job was marginally slower (8-11%) in my testing with 2.7 vs. 3.1; more than acceptable for me. (There's some variation in output, thanks to Unicode, but it's a variation that this project could live with.)
vicngtor 16y ago
Seriously rather than moving python 3 forward why can't they put in the effort to upgrade the most common libs so we all can go 3.0 first?
- masklinn 16y ago
  1. Because it's not really their job, the core team ports their own libraries and (as far as I know) are always available to help others do so for theirs. 2. Because some of the Python 3.2 fixes and improvements are needed for library migrations.
- dagw 16y ago
  Who are "they"? I imagine the overlap between people working on the core python language and people maintaining popular third party libraries is pretty small. Or are you suggesting that Van Rossum and friends drop python development for a year and start hacking on NLTK and PIL instead?
- xiongchiamiov 16y ago
  Have you read PEP 3003? Python 3 is hardly moving forward. http://www.python.org/dev/peps/pep-3003/ http://www.python.org/dev/peps/pep-3003/
  - briancurtin 16y ago
    I think it would benefit you to read the PEP before making such a post.
    - xiongchiamiov 16y ago
      I have read it, but evidently I'm misunderstanding something, either in the parent post or the PEP. Would you care to be a bit more explicit in pointing it out?
hartror 16y ago
The main question I have is when-will/should projects begin moving to 3.x?
- briancurtin 16y ago
  If you can do it based on your dependencies and your time, I don't see why you wouldn't, given the following: * It's easiest to do when you don't have a wide range of versions to support. If you want to support 2.6, 2.7, and 3.x, writing a single codebase that supports both versions is not really that hard. It gets harder the wider your range gets, but it's not impossible. For example: if you need 2.4-3.x then you don't have the `as` statement, so exception handling is tricker across all versions. * Run your code through `2to3`, it probably works. A lot of people are surprised at how close they are to working under 3.x, enough that there are some projects which successfully keep the codebase under 2.x and port to 3 via 2to3 only at release time. * You need good test coverage to have a successful port. Period. This is one of the barriers a lot of people see to porting -- they need to stop and build up tests before they can even think about moving forward. The initial effort in porting turns a lot of people off, as does the ongoing maintenance, especially when there's no audience for it, but as with the movie Field of Dreams: "if you build it, they will come". We need more projects to be proactive and spend a little time if they can...enough that the PSF will fund porting sprints (see www.pythonsprints.com)
  - vog 16y ago
    No offense intended, but I think that using `2to3` at release time is exactly the wrong way around. I'd rather like to have something like `3to2`. The idea is to use `2to3` only initially to move your code to Python3. From then on, develop your code in Python3 – that's what "we all" want, don't we? At release time, use `3to2` to also provide a Python2 version.
    - cdavid 16y ago
      It is definitely not the recommended nor the common way of doing it. Many projects use 2to3 at release time (which hopefully include testing time) to support python 3.x. Numpy and scipy do exactly that for example, and we won't limit ourselves to python 3.x anytime soon.
pero 16y ago
Would someone to care to chime in on an estimate as to when it would be advisable for amateurs to start employing 3.x? How far along are the libraries and the documentation/tutorials?
- xiongchiamiov 16y ago
  Use 3.x if you can. Use 2.x if a library you require hasn't been ported (or better, help them with it, although that's probably not a job for a self-described amateur).
  - saurik 16y ago
    The problem with that plan is that you might not need a 2.x library right now, but when you need one tomorrow you're going to be really sad. In essence, Python 3.x is a brand new niche/minority language, and should be treated as such by people thinking of using it.
- briancurtin 16y ago
  As for docs and tutorials, I wrote one myself for the PSF Sprints group at http://docs.pythonsprints.com/python3_porting/ http://docs.pythonsprints.com/python3_porting/. Brett Cannon just came out with http://docs.python.org/dev/howto/pyporting.html http://docs.python.org/dev/howto/pyporting.html a few weeks ago. Both of these docs have a references section which lists a number of other porting guides that we borrowed from. Library support is so-so. It's actually surprising how many libs out there could be have an initial port completed in an hour. I would encourage anyone to look at a dependency of theirs, run it through 2to3, then see what it does. Sometimes it's as easy as making a few fixes and it runs fine. Obviously there are complicated projects out there where this isn't true, but I don't think there needs to be any distinction between amateur and professional porting levels. Just go for it. As I said in another post, taken from the movie Field of Dreams: "if you build it, they will come."
- po 16y ago
  I hate the name (because I don't think it's shameful) but this gives a good idea of where things are: http://python3wos.appspot.com/ http://python3wos.appspot.com/ For most people, the docs/tutorials aren't that big a deal because the differences aren't that great. If you're just beginning I would say read up on the differences between 2.x and 3 so you're aware of it but wait until the majority of projects are ported.
bayareaguy 16y ago
One interesting thing from the "What's new in 3.2?"[1] page: After the 3.2 release, there are plans to switch to Mercurial as the primary repository. This distributed version control system should make it easier for members of the community to create and share external changesets. See PEP 385 for details. 1- http://docs.python.org/dev/whatsnew/3.2.html http://docs.python.org/dev/whatsnew/3.2.html
- cletus 16y ago
  Some background: http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-other-dvcss http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-... The reasoning was a bit odd (right at the end). For example: > First, git's Windows support is the weakest out of the three DVCSs being considered... True... kinda. In my experience it sucks unless you use Cygwin. I'm not sure how much that matters however. There is excellent tool support for Git on Windows, namely Jetbrains' IntelliJ (with the Python module) or PyCharm. Version control integration is one of those things that Jetbrains excels at with nobody else really coming close. But, then again, the vim/Emacs Python crowd (over IDEs) are still pretty strong. I'd be interested to know what the "core developers" disliked about Git too.
  - ylem 16y ago
    I find tortoisegit to be rather good for simple merges/commits on windows. For linux/macOS I just use the command line.
  - elithrar 16y ago
    > I'd be interested to know what the "core developers" disliked about Git too. I seem to recall part of the attraction of Mercurial was that it's written in Python.
  - henryprecheur 16y ago
    > I'd be interested to know what the "core developers" disliked about Git too. I spoke to Brett Cannon --basically the guy who chose Mercurial-- not long after the choice was made. Apparently the most important factor was that Mercurial was the favorite choice in the Python community. That's probably because Mercurial is written in Python, and was used by a lot of Python projects. Also Git didn't work very well under Windows at the time if I remember correctly.
tmsh 16y ago
Anybody done or know of any performance comparisons? Particularly intrigued by: http://docs.python.org/dev/whatsnew/3.2.html#multi-threading http://docs.python.org/dev/whatsnew/3.2.html#multi-threading http://mail.python.org/pipermail/python-dev/2009-October/093321.html http://mail.python.org/pipermail/python-dev/2009-October/093...
- wyuenho 16y ago
  I'm kinda curious too.
  - bluekeybox 16y ago
    Since the GIL is still there, I doubt that any drastic improvement has been achieved. Basically, instead of getting significantly worse performance when using threads, you will get close to single-threaded performance. Not better performance.
yason 16y ago
Python 2.6 as a language is "good enough", for whatever meaning of that phrase. What would be exciting in Python development is the PyPy + LLVM (and the short stretch of the Unladen Swallow project) backend, and applying the modern optimization techniques for compiling dynamic code into efficient machine code. There is IronPython etc. but the platform is different from CPython's.

Python 3.2 Released

142 points by mattyb 16y ago

steve918 16y ago

Sweet, now when is WSGI going to have 3.0 compatibility worked out so that it's reasonable to start using it?

henryprecheur 16y ago
We still need to wait for WSGI based frameworks and wrappers like Django, werkzeug, WebOb, etc. to be ported. It shouldn't be too long though. I'd bet that in 6 months 1 or 2 projects will already be functional.

xiongchiamiov 16y ago

The concurrent.futures module looks interesting: http://docs.python.org/dev/whatsnew/3.2.html#pep-3148-the-concurrent-futures-module http://docs.python.org/dev/whatsnew/3.2.html#pep-3148-the-co... I don't have much experience in that area, so I can't judge if it's as cool as I think it is. Will anyone help me out? The ability to safely convert string representations of data structures into the structures themselves seems pretty sweet, too: http://docs.python.org/dev/whatsnew/3.2.html#ast http://docs.python.org/dev/whatsnew/3.2.html#ast

mattgreenrocks 16y ago
> I don't have much experience in that area, so I can't judge if it's as cool as I think it is. Will anyone help me out? It is quite cool. Strictly speaking, it doesn't have to be in standard library, but Python has always had a batteries-included mentality anyway. Besides, it offers a more sane way to parallelize execution than mutexes, and that mentality should be encouraged. The entire java.util.concurrent.* library is quite good, actually. No shame in porting it.

kbatten 16y ago

If I could easily update python so that yum still worked fine on centos I would definitely start using python3. As it is I'm still stuck with python2.4 for a majority of the stuff I write.

Maascamp 16y ago
You can always use virtualenv and whatever version of Python you want.
lmz 16y ago
The IUS repository http://iuscommunity.org/ http://iuscommunity.org/ has Python 3 (and Python 2.6) packages that install side by side.
njharman 16y ago
You can always install other versions of Python. I have never used the distro's version of Python. I have always built my preferred version from source. It's trivial.

jefe78 16y ago

This is both wonderful and disappointing. We're still pretty locked into 2.6. I'd love to move to 3.2 but it would break EVERYTHING!!!!(! added for emphasis!) Maybe in ~10 years, everyone will be using 3.2, I know I can't wait! :D

wisty 16y ago
Remember the break from Numeric to numpy / scipy.core? Matplotlib managed to port OK, which was not small feat. The fact that you could do lots of try/excepts helped: try: import Numeric as np newaxis = np.NewAxis ... else: import numpy as np newaxis = np.newaxis I think that was about 10 years ago. It took ~5 years to gain acceptance. Python 3 is < 2.5 years old (3.0 final was Dec, 2008), so it's not doing that badly. The big problem seems to be whether both versions can run off the same source base, even with some voodoo (i.e. defining print functions, etc).
dochtman 16y ago
Move to 2.7 first, which should be fairly easy. From there, moving on to 3.x is much easier.
- logic 16y ago
  Agreed. Once I made the mental decision to stop supporting Python < 2.7, I ended up with at least one code base that runs under both 2.7 and 3.2. Switching to print() ("from __future__ import print_function"), basing error objects on Exception instead of StandardError, and wrapping loops over .items() or .keys() with list() were the only significant changes, and all of the above are available in 2.7. Runtime for a typical job was marginally slower (8-11%) in my testing with 2.7 vs. 3.1; more than acceptable for me. (There's some variation in output, thanks to Unicode, but it's a variation that this project could live with.)

vicngtor 16y ago

Seriously rather than moving python 3 forward why can't they put in the effort to upgrade the most common libs so we all can go 3.0 first?

masklinn 16y ago
1. Because it's not really their job, the core team ports their own libraries and (as far as I know) are always available to help others do so for theirs. 2. Because some of the Python 3.2 fixes and improvements are needed for library migrations.
dagw 16y ago
Who are "they"? I imagine the overlap between people working on the core python language and people maintaining popular third party libraries is pretty small. Or are you suggesting that Van Rossum and friends drop python development for a year and start hacking on NLTK and PIL instead?
xiongchiamiov 16y ago
Have you read PEP 3003? Python 3 is hardly moving forward. http://www.python.org/dev/peps/pep-3003/ http://www.python.org/dev/peps/pep-3003/
- briancurtin 16y ago
  I think it would benefit you to read the PEP before making such a post.
  - xiongchiamiov 16y ago
    I have read it, but evidently I'm misunderstanding something, either in the parent post or the PEP. Would you care to be a bit more explicit in pointing it out?

hartror 16y ago

The main question I have is when-will/should projects begin moving to 3.x?

briancurtin 16y ago
If you can do it based on your dependencies and your time, I don't see why you wouldn't, given the following: * It's easiest to do when you don't have a wide range of versions to support. If you want to support 2.6, 2.7, and 3.x, writing a single codebase that supports both versions is not really that hard. It gets harder the wider your range gets, but it's not impossible. For example: if you need 2.4-3.x then you don't have the `as` statement, so exception handling is tricker across all versions. * Run your code through `2to3`, it probably works. A lot of people are surprised at how close they are to working under 3.x, enough that there are some projects which successfully keep the codebase under 2.x and port to 3 via 2to3 only at release time. * You need good test coverage to have a successful port. Period. This is one of the barriers a lot of people see to porting -- they need to stop and build up tests before they can even think about moving forward. The initial effort in porting turns a lot of people off, as does the ongoing maintenance, especially when there's no audience for it, but as with the movie Field of Dreams: "if you build it, they will come". We need more projects to be proactive and spend a little time if they can...enough that the PSF will fund porting sprints (see www.pythonsprints.com)
- vog 16y ago
  No offense intended, but I think that using `2to3` at release time is exactly the wrong way around. I'd rather like to have something like `3to2`. The idea is to use `2to3` only initially to move your code to Python3. From then on, develop your code in Python3 – that's what "we all" want, don't we? At release time, use `3to2` to also provide a Python2 version.
  - cdavid 16y ago
    It is definitely not the recommended nor the common way of doing it. Many projects use 2to3 at release time (which hopefully include testing time) to support python 3.x. Numpy and scipy do exactly that for example, and we won't limit ourselves to python 3.x anytime soon.

pero 16y ago

Would someone to care to chime in on an estimate as to when it would be advisable for amateurs to start employing 3.x? How far along are the libraries and the documentation/tutorials?

xiongchiamiov 16y ago
Use 3.x if you can. Use 2.x if a library you require hasn't been ported (or better, help them with it, although that's probably not a job for a self-described amateur).
- saurik 16y ago
  The problem with that plan is that you might not need a 2.x library right now, but when you need one tomorrow you're going to be really sad. In essence, Python 3.x is a brand new niche/minority language, and should be treated as such by people thinking of using it.
briancurtin 16y ago
As for docs and tutorials, I wrote one myself for the PSF Sprints group at http://docs.pythonsprints.com/python3_porting/ http://docs.pythonsprints.com/python3_porting/. Brett Cannon just came out with http://docs.python.org/dev/howto/pyporting.html http://docs.python.org/dev/howto/pyporting.html a few weeks ago. Both of these docs have a references section which lists a number of other porting guides that we borrowed from. Library support is so-so. It's actually surprising how many libs out there could be have an initial port completed in an hour. I would encourage anyone to look at a dependency of theirs, run it through 2to3, then see what it does. Sometimes it's as easy as making a few fixes and it runs fine. Obviously there are complicated projects out there where this isn't true, but I don't think there needs to be any distinction between amateur and professional porting levels. Just go for it. As I said in another post, taken from the movie Field of Dreams: "if you build it, they will come."
po 16y ago
I hate the name (because I don't think it's shameful) but this gives a good idea of where things are: http://python3wos.appspot.com/ http://python3wos.appspot.com/ For most people, the docs/tutorials aren't that big a deal because the differences aren't that great. If you're just beginning I would say read up on the differences between 2.x and 3 so you're aware of it but wait until the majority of projects are ported.

bayareaguy 16y ago

One interesting thing from the "What's new in 3.2?"[1] page: After the 3.2 release, there are plans to switch to Mercurial as the primary repository. This distributed version control system should make it easier for members of the community to create and share external changesets. See PEP 385 for details. 1- http://docs.python.org/dev/whatsnew/3.2.html http://docs.python.org/dev/whatsnew/3.2.html

cletus 16y ago
Some background: http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-other-dvcss http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-... The reasoning was a bit odd (right at the end). For example: > First, git's Windows support is the weakest out of the three DVCSs being considered... True... kinda. In my experience it sucks unless you use Cygwin. I'm not sure how much that matters however. There is excellent tool support for Git on Windows, namely Jetbrains' IntelliJ (with the Python module) or PyCharm. Version control integration is one of those things that Jetbrains excels at with nobody else really coming close. But, then again, the vim/Emacs Python crowd (over IDEs) are still pretty strong. I'd be interested to know what the "core developers" disliked about Git too.
- ylem 16y ago
  I find tortoisegit to be rather good for simple merges/commits on windows. For linux/macOS I just use the command line.
- elithrar 16y ago
  > I'd be interested to know what the "core developers" disliked about Git too. I seem to recall part of the attraction of Mercurial was that it's written in Python.
- henryprecheur 16y ago
  > I'd be interested to know what the "core developers" disliked about Git too. I spoke to Brett Cannon --basically the guy who chose Mercurial-- not long after the choice was made. Apparently the most important factor was that Mercurial was the favorite choice in the Python community. That's probably because Mercurial is written in Python, and was used by a lot of Python projects. Also Git didn't work very well under Windows at the time if I remember correctly.

tmsh 16y ago

Anybody done or know of any performance comparisons? Particularly intrigued by: http://docs.python.org/dev/whatsnew/3.2.html#multi-threading http://docs.python.org/dev/whatsnew/3.2.html#multi-threading http://mail.python.org/pipermail/python-dev/2009-October/093321.html http://mail.python.org/pipermail/python-dev/2009-October/093...

wyuenho 16y ago
I'm kinda curious too.
- bluekeybox 16y ago
  Since the GIL is still there, I doubt that any drastic improvement has been achieved. Basically, instead of getting significantly worse performance when using threads, you will get close to single-threaded performance. Not better performance.

yason 16y ago

Python 2.6 as a language is "good enough", for whatever meaning of that phrase. What would be exciting in Python development is the PyPy + LLVM (and the short stretch of the Unladen Swallow project) backend, and applying the modern optimization techniques for compiling dynamic code into efficient machine code. There is IronPython etc. but the platform is different from CPython's.