
Python 3.3.0 released - cx01
http://python.org/download/releases/3.3.0/
======
po
The real advantage here is the release of Armin's u'' syntax addition
proposal:

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

In a nutshell, the 2.x version of declaring a unicode string is now valid
(although redundant). From the PEP:

 _In many cases, Python 2 offered two ways of doing things for historical
reasons. For example, inequality could be tested with both != and <> and
integer literals could be specified with an optional L suffix. Such
redundancies have been eliminated in Python 3, which reduces the overall size
of the language and improves consistency across developers._

 _In the original Python 3 design (up to and including Python 3.2), the
explicit prefix syntax for unicode literals was deemed to fall into this
category, as it is completely unnecessary in Python 3. However, the difference
between those other cases and unicode literals is that the unicode literal
prefix is not redundant in Python 2 code: it is a programmatically significant
distinction that needs to be preserved in some fashion to avoid losing
information._

This version of python should see more uptake by 2.x developers as it is now
easier to port.

~~~
slurgfest
Although it was a pain, it was manageable beforehand and in fact, if you need
to support 3.1 or 3.2, you will still have to manage it a different way.

Many of the features detailed in the release list are more helpful in general.
'yield from' is actually really good if you are using generator based
coroutines, the wide/narrow build thing addresses a long-time pain point, it
will be great if namespace packages are actually fixed by now, and adoption of
virtualenv into the core is a big deal!

------
vph
There are two significant factions in the Python community: the scientific
group and the web-dev group. The scientific group is pretty much on board with
Python 3. Perhaps due to unicode handling intricacies, that the web-dev group
ain't exactly on board with Python 3 yet. But this needs to change and it
takes leadership. Fortunately, bit and pieces such as webob are Python 3
compatible. And personally, I feel the Python web frameworks need a fresh
redesign.

~~~
wwwtyro
I work in both camps, and I always felt it was the web developers that were
better about moving on to 3. Scientists in general are loathe to risk breaking
well-tested code for the sake of new features. In my research group, in fact,
we've just barely moved on to 2.7 from 2.4! I doubt there will be any
motivation at all for moving to 3 any time soon.

~~~
slurgfest
I doubt that web developers are better about it, my reasoning follows:

The #1 Python web framework, Django, is a bit ahead of the curve but still
hasn't released a major version that supports 3. Django's huge ecosystem of
addons are not going to catch up for some time after that. And users are not
going to develop green-field Django apps on Python 3 until some time after
that. So the timeline for serious use of Python 3 with Django should still be
counted in years, which means that the majority of Python web development will
not be done with Python 3 for a while. (If Flask and Werkzeug had been out
ahead of this issue, it could have eaten up even more of Django's market
share, but it looks like it will actually be behind in adopting Python 3). I
don't think any of the Zope frameworks or ZODB, etc. support 3. And I think
between those three you probably have most of Python web development accounted
for.

Pyramid, Bottle, Tornado and CherryPy DO support Python 3 but aren't nearly as
widely used. App Engine needs a new runtime and that could be years. I don't
think that Web2py or web.py have released versions which support Python 3,
though both probably have something in the works.

Since web development is so heavily framework-driven, the majority of web
development on Python is not going to move on to 3 until Django and Flask
ecosystems move over, or everyone switches to Pyramid.

And due to the requirement for backward compatibility, Python 3 features will
not be widely used for a while (suppose you make a widely used extension, you
are not going to lock out people using 2.7, this means you are using the
common denominator of features and supplying Python 2 implementations for the
stuff you are using from new Python 3 libraries).

I would contrast this with the very large number of general Python libraries
which already support Python 3. So I think the Python web development world is
well behind the rest of the Python world.

It's a mess but I think that Python 3's improvements are worth not
straitjacketing the future of the language into the decisions made in 2.

~~~
magnusgraviti
At KyivPy#8 I heard about new lightweight framework supporting Python3 -
wheezy.web. But as you said it is not a mainstream among web-developers.

I think the most popular Django apps will move to Python 3 as a lot of people
are interested in it. Time show us how Django with Python3 support will change
the current situation.

------
masklinn
Exciting. Python 3.3 is the first release of the Python 3 series which makes
me go from "I'll have to come around to use Python 3" to "dammit, why isn't my
codebase under Python 3 yet?". There's a bunch of neat stuff, minor and not so
minor.

~~~
reinhardt
Any specific examples that got you excited? I'm going through the new features
list and I can't point to one that wowed me.

~~~
masklinn
It's more of an accumulation of things ending up making 3.3 way superior to
3.2 in the end. But,

* The feature I like most is definitely generator delegation, it significantly improves more extensive uses of generators and iterators, and makes generator-as-coroutines a much more interesting proposition (before delegation, calling an other "coroutine" would be rather painful, now you essentially just have to tack a `yield from` in front, as you'd tack an `await` in C# 5.0)

* The flexible string representation finally fixes narrow build's issues with astral planes, which is becoming rather important as astral planes include e.g. emoji, and it significantly reduces the possibility of bugs when working with astral planes (as there's no more behavioral difference between "narrow" and "wide" builds)

* We'll have to see how they're used, but namespace support could be used to significantly cleanup of... well, namespaces (and multiple separate libraries living in the same namespace, without having to resort to PYTHONPATH hacks or setuptools tomfoolery)

* A built-in, clean implementation of contexts/scopes (collections.ChainMap) I can already see plenty of use for. Same for signatures, there's high hijinks potential in that one.

* The rest really is about a better experience all around: reduced memory, "unicode literals" (for Python 2 compat), ElementTree fixups, ...

------
tisme
I've done quite a bit of python development. One of the things that really
bugs me about python is how they keep breaking older stuff. Other languages
have been much more careful about maintaining backwards compatibility and I
think that is a big factor in the retention of users.

Having to re-do any part of your code from one release of a language to
another became a real deal breaker for me.

For an interpreted language that problem is even worse because you don't know
you have a problem until that bit of code gets hit.

~~~
stickfigure
Be careful what you wish for. The extreme alternative is Java, whose slavish
obsession with backwards compatibility has effectively crippled the language.
There's enough cruft in the standard library to keep newbies guessing for
years, plus fundamental language design failures like type erasure and
"beans".

At some point you need to burn bridges in order to move forward. Doing this
frequently destroys the community. Never doing it also destroys the community,
it just takes longer.

Personally, I think Python is managing pretty well. Yes, it's occasionally
painful, but it's less painful than stagnation.

~~~
human_error
I think in Python's case there was really no compelling reason to burn the
bridges between 2 and 3. Burning the bridges should be done when something
will be significantly improved.

~~~
dbaupp
Python's Unicode support was significantly improved between 2 and 3.

------
pkmays
Not mentioned among the major features: Windows builds have finally moved to
Visual Studio 2010.

~~~
csense
It seems strange to me that they use Visual Studio rather than mingw/msys. Do
any HN readers know why that is?

~~~
eropple
I don't know why they don't, but I'd give serious thought to not supporting
Windows at all if I had to use mingw/msys. And this is coming from somebody
whose first order of business on a Windows machine is to install cygwin. The
environment is just Not Friendly.

Visual Studio is the vendor-suggested way of building C++ and it's free
besides; there's not really a good reason not to use it.

~~~
csense
I've found mingw and msys to be very fast and easy to use.

In my experience it's been Cygwin that's a bloated, non-intuitive, awful
monstrosity to be avoided at all costs. I've had great difficulties in the
past with Cygwin DLL's, particularly when a program comes with its own Cygwin
DLL which is a different version than the system Cygwin.

I haven't used Cygwin since 2005 or so due to these difficulties.

For Windows virtualization solutions, my first stop these days would be
Virtualbox, qemu or the like. Second preference is mingw/msys.

I've also had a positive experience with a little-known solution called
Colinux [1], essentially a Windows port of another little-known technology in
the Linux mainline kernel called user-mode Linux. Colinux requires some setup,
especially if you want graphics (for GUI work, you need some remote desktop
with a Windows client like Xming or VNC). Again, I'd recommend VirtualBox or
qemu for casual use, but Colinux is an interesting technology, and I've found
it gets very good performance.

My negative experiences with Cygwin were so great, it is only something I use
when there is no alternative available. And in preference to all of these is
simply using Linux, but sometimes that's simply not an acceptable alternative
to Windows (i.e. when you're making a product that you want to run on all
popular OS's, supporting only Linux seems like a recipe for disaster. See Sage
[2] for an example of an open-source project whose official line on Windows
compatbility is "use Virtualbox.")

[1] <http://www.colinux.org/>

[2] <http://sagemath.org>

~~~
eropple
All your points (well, aside from mingw itself) are great ones. Cygwin is 100%
a monster. But it's a monster that works the way I expect it to. MSYS is often
lacking in things I consider basic that I miss going from OS X to Windows and
trying to configure it is a super-pain-in-the-ass.

Colinux is actually pretty cool, but the need for an X server and the setup
time is a pain in the ass.

------
endlessvoid94
> The Python interpreter becomes aware of a pvenv.cfg file whose existence
> signals the base of a virtual environment’s directory tree

As someone who hated the .ini configuration for logging in python 2.5, this
smells a bit.

~~~
TazeTSchnitzel
As someone who has used PHP and the infamous _php.ini_ , this worries me too.

------
sigzero
Here is what is new:

<http://docs.python.org/py3k/whatsnew/3.3.html>

------
Zenst
"•A C implementation of the "decimal" module, with up to 80x speedup for
decimal-heavy applications"

That in itself is should make a few python gamers happy. Also some serious
motivations for older version users, not all but more and more. Also many
other interesting develepments others have highlighted already.

~~~
janzer
And 80x is apparently actually an understatement, at least for a few cases.
Some numbers recently posted to python-dev show up to a 124X improvement:

    
    
      Precision: 9 decimal digits
    
      float:
      result: 3.1415926535897927
      time: 0.113188s
    
      cdecimal:
      result: 3.14159265
      time: 0.158313s
    
      decimal:
      result: 3.14159265
      time: 18.671457s
    
    
      Precision: 19 decimal digits
    
      float:
      result: 3.1415926535897927
      time: 0.112874s
    
      cdecimal:
      result: 3.141592653589793236
      time: 0.348100s
    
      decimal:
      result: 3.141592653589793236
      time: 43.241220s

~~~
Zenst
Impressive stuff, though what struck me was the results, least accuracy wise
and what rounding they using:

Pi is 3.14159 26535 89793 238....

So I do wonder what rounding they are using, even truncating as I have (next
digit 4 so good place to do that) then can see the last digit should at least
be 8, worst case 7 and 6!! There again this may be a convention or result of
the methord to calulate Pi.

As for floats, well, for accuracy I'd go with cdecimal right there, though is
it as accurate. I suspect it is the formular used that induces the minute
error in results.

<http://en.wikipedia.org/wiki/Pi> #21 reference

~~~
janzer
This is from the decimal benchmarks included in the python source[1], in the
recipe given in the decimal documentation[2] the precision is increased for
the intermediate steps of the algorithm so it gives the correct end result.

    
    
      >>> pi()
      Decimal('3.141592653589793238')
    

1\.
[http://hg.python.org/cpython/file/344d67063c8f/Modules/_deci...](http://hg.python.org/cpython/file/344d67063c8f/Modules/_decimal/tests/bench.py)

2\. <http://docs.python.org/library/decimal.html#recipes>

~~~
Zenst
Thank you, out of interest on a appliction I work on every now and then showed
a 50% improvement with the code as is, not heavy decimal at all, mostly int's
though still a nice speedup.

------
krosaen
I've always been uneasy about the increasing use of yield / generators in
python these days, for instance, ndb in google app engine, twisted, etc.
'yield from' should make managing more complex uses of generators much easier
- the question for me is, will this make me like widespread use of generators
more, or will it make the use even more widespread, and still be kind of a
pain to reason about, debug, etc.

------
coolnow
Which Python version would you recommend to someone just starting to learn the
language? I know "Learn Python the Hard Way" focuses on Python 2.7, and
"Learning Python (4th Edition)" focuses primarily on Python 3.

------
magnusgraviti
Attending PyCon Ukraine 2011 it was very interesting to hear about Distutils2.
But I see that in the end they are still not in Python3.

But even without it I am going to try Python3 in my projects (hello Django
1.5, Tornado, Wheezy.web, jinja2 and a lot of others).

------
Ixiaus
Programmer pr0n straight up. I can't wait for Pyramid 1.3.x to support Python
3.3!!!

------
TazeTSchnitzel
Built-in virtualenv? Finally!

------
sigzero
Very awesome!

------
johnisme
Cool!

------
sublimit
And not a single reason for me to stop using 2.7. It's been just bloat since
3.0.

~~~
masklinn
> It's been just bloat since 3.0.

I can't make head or tail of that claim, what's the "bloat since 3.0"?

~~~
nilliams
I'd tend to just ignore anyone that uses the word 'bloat' without backing
their statement up with any substance/insight or perhaps acknowledgement that
they may be wrong on some counts and are unlikely to understand the entire
problem-space of said project to the extent they can justify deeming any
significant portion of it unnecessary.

~~~
masklinn
Well sure, but maybe he has genuine and interesting issues with Python 3, and
maybe he just had a bad day, hasn't had his coffee yet or whatever and went
with a quip rather than a complete comment. That happens.

~~~
nilliams
Sure, but it's lazy either way. Cries of 'bloat' without some supporting
reasoning = alarms bells suggesting willful ignorance to me.

Personally gets my goat a lot at work. It's so easy to allude to bloat, or
(for example) some framework containing _'stuff you don't need'_ instead of
doing your homework and making an effort to understand why that _stuff_
exists.

------
castles
It's time

~~~
castles
The `whole greater than the tally` feature set and performance improvements of
this release, really has inched Python 3 to the point where I will want to
_start_ using it. With no basis beyond my own and other's like sentiment this
still seems like an important milestone. Feel like many will move from
inertiaville, at least building a weekend house in momentum town.

