
What’s New In Python 3.3 - ch0wn
http://docs.python.org/dev/whatsnew/3.3.html
======
overshard
I find a lot of 3.x new features to be improvements from 2.x but everyone
still uses 2.x. I fear that we will be on Python 4.x by the time 3.x adoption
starts to actually happen en masse.

From what me and my coworkers have discussed we are basically all waiting on
Django to get Python 3.x adoption. I've tried submitting multiple patches for
this and helping Django as much as possible but they don't seem to want
outside help.

Come on Django, come on, a lot of us are waiting for you.

~~~
tbatterii
then there's appengine, just now got up to 2.7. it will probably be another
few years before it's on 3.x. doesn't fedora still ship with 2.4? ideally we
would all like new toys, but reality sucks most of the time.

~~~
dagw
_doesn't fedora still ship with 2.4_

You're confusing Fedora and Red Hat. Fedora is generally very cutting edge and
has been shipping with 2.7 for quite a while now, Red Hat is far more
conservative and was, at least up until the latest release, shipping with 2.4

~~~
sunqiang
for RHEL 5, it's Python 2.4, for RHEL 6 it's Python 2.6.

------
amix
I am not really that excited about any of these features that's in 3.3 (or
even in Python 3).

The biggest problem I have is that Python 2 works "good enough" and upgrading
to Python 3 does not have many benefits, other than lots of work and slower
performance. I guess a lot of people feel the same way, hence the slow or non
existing adoption of Python 3. I guess Python 3 might end up as Perl 6 if this
continues since we keep investing time on Python 2.x libraries and features.

What we need is a reason to upgrade and the killer feature of Python 3 could
be performance. I would upgrade to Python 3 in a instance if it offered a lot
better performance than Python 2.

How do we achieve better performance? Adopt PyPy as the reference
implementation for Python 3 and all future references. Making PyPy a
centerpiece of Python 3+ would probably mean it would mature faster.

PyPy is focused right now on Python 2.X, but I would rather see it focus on
the future of Python and being a killer feature of Python 3+.

~~~
agentultra
I find your claims are unsubstantiated and would require some evidence to be
convincing.

For example, the performance of Python 3.0 was slow on I/O operations. The
reason was because the I/O modules were written in pure-python in order to get
the ball rolling. This wasn't a bug. However, the code was eventually ported
to C in 3.1 and unsurprisingly the performance improved:
[http://www.gtsystem.eu/blog/2009/08/improved-performance-
of-...](http://www.gtsystem.eu/blog/2009/08/improved-performance-of-
python-31/)

And that's an old post from 2009! The performance is much better today.

Features they're releasing in this new version include zero-copy in
os.copyfile() which is totally sweet. No user-space buffers involved in
transferring bytes from a file to a socket. This should speed up such
operations well past what any version of python 2.x is capable of.

There isn't a feature in Python 3 that is not substantially better than 2.x --
they're fixing all the fiddly bits and producing a much better language. There
is no feature they can create which will open the dam to a flood of porting
projects. The reason is that the problem is a social one.

An honest-to-goodness effort to port the large libraries requires a plan to
support the existing 2.x versions alongside the 3.x versions so that the
people who are still running applications built on the old versions will still
work. This requires extra effort that is difficult to acquire in open source
projects let alone commercial ones.

Even if the Python 3 devs added a feature that materialized ponies out of thin
air there would still be projects running the 2.x code.

~~~
enjo
Yep. I won't port a single bit of my existing code until 100% of the libraries
I depend on are ported first. As much as I like Python 3, it just doesn't make
any sense for me to deal with it right now.

~~~
agentultra
Part of what I was trying to get across is that there will never be a
compelling reason to make the port. It will never "make sense" so long as what
you have now continues to work.

If you're ever going to make the port, _you_ have to decide to do it and make
the effort. Nothing the Python 3 devs release will ever convince you to port
otherwise.

------
agentultra
I'm pretty excited for the small changes like zero-copy and the 'x' file open
flag. Oh, and the new OSError exception hierarchy.

Some of these things could be back-ported to Python 2.7 as libraries but I'd
much rather see a bigger push to move onto Python 3 instead.

I look forward to even more Python 3 awesomeness in the future. Each release
is a compelling reason to start porting.

~~~
riobard
I wish they could add os.splice() and os.tee() on Linux, too.

------
kamaal
Should we develop on Python 3.x series or 2.x series?

Libraries aren't really ready for 3.x series and developing on 2.x series is
not making any sense as if 2.x ultimately goes away then migration effort on
that is not worth.

At the same time 3.x ecosystem is not ready either.

~~~
jacobian
The general advice I give is: "Python 3 if you can, Python 2 if you must."

That is, if you _can_ use Python 3, you should: it's the future of the
language, and it feels it. I find Python 3 significantly more pleasant than
Python 2; nearly all the bits that annoy me about Python are fixed in 3.
Python 3 is cleaner, the standard library is de-crufted and easier to
navigate, and (most important to me) handling unicode doesn't suck.

However, as others in this thread note, significant parts of the Python
ecosystem haven't finished porting yet (Django, Twisted, yada yada yada). If
you rely on one of those things, then stick with Python 2. If that code lives
fo a long time you will have to face a porting effort later on, but that's
improving somewhat as the community discovers new techniques and creates new
tools.

------
Flimm
The os module now has a new function: pipe2. Is there a reason why they didn't
give it a better name, like pipe_with_flags?

~~~
wulczer
The underlying syscall and libc function are called pipe2.

------
tocomment
I think they really need a killer feature in the 3.x branch to drive adoption.
Any ideas?

~~~
sho_hn
I don't think they do, myself. Adoption will and is happening gradually. More
and more libs are being ported, and new Python coders often learn "Python 3
and how 2 differs" (rather than the other way around), e.g. thanks to Lutz'
book. Eventually there just won't be any reasons left to use 2, and the usual
reasons to use the latest version kick in - incremental improvements and
continued maintenance.

The migration was always expected to be a long-term thing, and so far has been
pretty pain-free imho. But then I haven't written any code that doesn't run in
3.x since 2010, finding that 3 increasingly meets my deps and is more
enjoyable and productive to code in, and when I do need to support 2 that the
common subset of 2.7 and 3 is large enough to do many things.

~~~
tocomment
What makes 3 more enjoyable/productive?

~~~
sho_hn
Unicode strings by default is a big one for me, but the little things sum up
too: The removal of x*() functions in favor of making things that should
return iterators just do so, removing old-style classes, various little
consistency gains in standard object interfaces/protocols, lots of standard
lib organization cleanups. I simply find things in Python 3 are the way I
expect or want them to be more often than in 2, reducing the number of gotchas
I need to keep track of. Heck, even print() is a solid improvement in my book
(keyword args, hooray!) and I appreciate not needing the __future__ import for
it.

The list gets longer of course if you fairly add all the things eventually
backported to 2.7, e.g. set literals and comprehensions.

So, does 2.x work? Sure. Is 3 better? Yup. If I get to pick one, I pick 3.

------
ramanujan
Unfortunately, Python 3 is the new Perl 6. It offers reduced performance[1],
changes some of the hardest-to-debug parts of the language (like Unicode), and
capriciously introduces backwards incompatibilities. For no obvious gain!

As just one example, could Guido not have made the print statement a function
through the simple mechanism of:

    
    
      from __future__ import printfn
    

Then new code could use printfn and old code could use print, and all would be
well. But instead, literally billions of dollars will be wasted changing every
single print keyword statement to a print function invocation. Sure, you can
use 2to3. But the tool is that worst of all worlds, a compiler that doesn't
really work 100% and actually reduces the performance of your code in the
compilation process.

For those who do not want to waste their time on this port, Python 3 is going
to accelerate the move towards full stack JS just like Perl 6 accelerated the
move towards Python/Ruby. This JS stack will be MongoDB + node +
Backbone/coffeescript or some similar permutation.

After all, if you are going to literally have to recompile your language with
2to3 and deal with all the edge cases, why not go whole hog with something
like emscripten[2] or a souped-up pyjamas[3] to convert your legacy Python 2
code to JS? Then people just need to start porting C/C++ numerical libraries
over to V8 through something like v8-juice[4] and we will have all the missing
pieces.

[1]
[http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...](http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance)

[2] <https://github.com/kripken/emscripten/wiki>

[3] <http://pyjs.org/>

[4] <http://code.google.com/p/v8-juice/>

~~~
briancurtin
>
> [http://docs.python.org/release/3.0.1/whatsnew/3.0.html#perfo...](http://docs.python.org/release/3.0.1/whatsnew/3.0.html#performance)

The thread is about 3.3, so you link to a 3.0.1 release note? That is three
years old.

> literally billions of dollars will be wasted changing every single print
> keyword statement to a print function

I'd love to see the math on this, especially because I did it in a matter of
minutes across all of my code.

~~~
ramanujan
> 3 years old

I'm pretty sure they'd have announced it if Python 3 ever got faster than
Python 2. But this is not mentioned in the 3.1, 3.2, or 3.3 notes on
performance:

    
    
      http://docs.python.org/dev/whatsnew/3.1.html#optimizations
      http://docs.python.org/dev/whatsnew/3.2.html#optimizations
      http://docs.python.org/dev/whatsnew/3.3.html#optimizations
    

> see the math

That one is easy. The Python 3 conversion is a serious project for core devs
at Django and Numpy. Check out their mailing lists about what this takes/took.

[http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-
sc...](http://blog.jarrodmillman.com/2009/01/when-will-numpy-and-scipy-
migrate-to.html)

    
    
      While the above procedure of using the 2to3 tool works 
      relatively for pure Python code, there is no automatic 
      conversion tool for extension code. NumPy is mostly 
      written in C and makes extensive use of the Python C-API. 
      So converting NumPy will require much more than running 
      the 2to3 tool.
    

[https://docs.djangoproject.com/en/dev/faq/install/#can-i-
use...](https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-
with-python-3)

    
    
      ... it will be a while before most Python software catches 
      up and is able to run on Python 3.0. For larger Python-
      based software like Django, the transition is expected to 
      take at least a year or two (since it involves dropping 
      support for older Python releases and so must be done 
      gradually).
    

A "year or two" of the core Django team's time is easily several million
bucks. Multiply by the Python codebases of every company on this list [1], and
everyone on github, and every egg out there, and we are talking billions for
the conversion.

[1] <http://wiki.python.org/moin/OrganizationsUsingPython>

~~~
ldite
> I'm pretty sure they'd have announced it if Python 3 ever got faster than
> Python 2.

According to this blog post, 3.2 performance now exceeds 2.6 and 2.7, using
the same pystone benchmark that the 3.0 release notes refer to:

[http://www.levigross.com/post/2340736877/pystone-
benchmark-o...](http://www.levigross.com/post/2340736877/pystone-benchmark-
on-2-6-2-7-3-2)

~~~
temphn
From the full article, "Python 3.2 [beta] looks promising coming out just a
little faster than Python 2.7.". This same article has PyPy coming in at 3
times as fast as Python 3.2 and Python 2.7 on the pystone benchmark, but if
you have used PyPy it is not fast.

Looks like we need another benchmark. Does anyone have the Python 2 code from
the Shootout? It seems to have been removed so that you can no longer compare
Python 3 to Python 2 directly.

[http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=yarv)

