
Python 3.2 Released - mattyb
http://www.python.org/download/releases/3.2/
======
bayareaguy
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>

~~~
cletus
Some background:

[http://www.python.org/dev/peps/pep-0374/#why-mercurial-
over-...](http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-other-
dvcss)

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.

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

~~~
masklinn
> Also Git didn't work very well under Windows at the time if I remember
> correctly.

Yep, Windows wasn't well supported so it was a pain to setup, and it was very
very slow.

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

------
xiongchiamiov
The concurrent.futures module looks interesting:
[http://docs.python.org/dev/whatsnew/3.2.html#pep-3148-the-
co...](http://docs.python.org/dev/whatsnew/3.2.html#pep-3148-the-concurrent-
futures-module)

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>

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

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

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

~~~
vog
_> definitely not the recommended nor the common way_

Indeed, this proposal is not the common way. But why is that so uncommon?

Why is using 3to2 not recommended? In how far do you limit yourself if you
develop in Python3 and use 3to2 at release time?

Rather, I'd guess that developing in Python2 and using 2to3 is limiting,
because that limits you to the language features of Python2.

~~~
cdavid
The context I was speaking is projects who still want to support 2.x, which is
what most projects want.

Obviously, if you don't care about supporting 2.x at all once the conversion
is done, modifying the output and using the output as your reference source is
fine.

~~~
vog
_> The context I was speaking is projects who still want to support 2.x_

This is also what I was speaking about. And to reach that goal, you have
generally 3 options:

1) write code that works with Python2 as well as Python3

2) maintain your code in Python2 and use 2to3 on release time

3) maintain your code in Python3 and use 3to2 on release time

Given you don't want to do 1) for whatever reason, my argument is that 3)
seems to be the preferable solution. It allows you to use our loved Python3
right now, while still supporting Python2.

However, "in the wild" we see 2) way more often, and I don't understand why
this is the case.

Why do so many projects prefer 2) over 3)?

~~~
cdavid
Because for many contributors, python 3 is not usable as there are so few
packages available. And on the other hand, the improvements from python 2 -> 3
are really minor.

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

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

------
tmsh
Anybody done or know of any performance comparisons? Particularly intrigued
by:

<http://docs.python.org/dev/whatsnew/3.2.html#multi-threading>

[http://mail.python.org/pipermail/python-
dev/2009-October/093...](http://mail.python.org/pipermail/python-
dev/2009-October/093321.html)

~~~
wyuenho
I'm kinda curious too.

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

------
kbatten
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
You can always use virtualenv and whatever version of Python you want.

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

------
vicngtor
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?

~~~
xiongchiamiov
Have you read PEP 3003? Python 3 is hardly moving forward.

<http://www.python.org/dev/peps/pep-3003/>

~~~
briancurtin
I think it would benefit you to read the PEP before making such a post.

~~~
xiongchiamiov
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?

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

~~~
dochtman
Move to 2.7 first, which should be fairly easy. From there, moving on to 3.x
is much easier.

~~~
logic
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.)

