Python 3.3.0 Released

An anonymous reader writes "After just over a month of release candidates, the final version of Python 3.3 launched today. This version includes new syntax, including the yield from expression for generator delegation; new library modules, including fault handler (for debugging crashes), ipaddress, and lzma (for data compression using the XZ/LZMA algorithm); a reworked OS and I/O exception hierarchy; the venv module for programmatic access to Python virtual environments; and a host of API changes. The full list of features and the change log are both available."

Re:Python 3 and its use

[wisty]

I think Ubuntu is going Python 3. Most of the scientific stuff has been ported (though the Matplotlib port may be immature).

Bottle, Pyramid, and Tornado are all ported. Just not Django.

It's probably now at the point where new projects are better off starting with Python 3, to ease the pain of upgrading later, unless there's a library they really need. Starting with a mature (but depreciated) platform is not a great idea.

Re:Python 3 and its use

[Zamphatta]

In mid-August, Django had a blog post 'Experimental Python 3 Support' (https://www.djangoproject.com/weblog/2012/aug/19/experimental-python-3-support/), which talked about the progress they've made so far towards porting the system to Python 3 and how it's coming along well. It's to be considered pre-alpha at the moment, but there's been a lot of progress over this summer.

Re:Python 3 and its use

[buchner.johannes]

Killing Python 2 is going to be like killing IE6 and Windows XP - a noble goal that turns out to take decades. And it's a totally self-inflicted wound by the Python community.

Except nobody intends to kill Python 2 anytime soon. When Python 3 was shaped, it was everyones plan to have Python 2 + 3 alongside for a long time.

Re:Python 3 and its use

[csumpi]

That might be the case, except:

#!/bin/env python

might give you python2 or python3. And there's no standardized way to ask for python2 or python3.

Re:Python 3 and its use

[lattyware]

You say that, PEP 394 -- The "python" Command on Unix-Like Systems [python.org] clearly defines this:

This PEP provides a convention to ensure that Python scripts can continue to be portable across *nix systems, regardless of the default version of the Python interpreter (i.e. the version invoked by the python command).

• python2 will refer to some version of Python 2.x
• python3 will refer to some version of Python 3.x
• python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions

Pretty clear and standardised to me.

Re:Python 3 and its use

[Anonymous Coward]

Googler here. Python is only used in legacy applications -- all new code is written in Go.

Re:Because .py3 wasn't used

[Anonymous Coward]

The launcher is added with 3.3 and suppose you can install it separately too.
http://docs.python.org/dev/using/windows.html#launcher

Tried and had no problems with python2.7 and python3.3 installed

Re:Because .py3 wasn't used

[Waffle Iron]

One reason why Python 3 hasn't taken off is that it didn't adopt .py3 as a file name suffix for Python 3 programs.

A lot of the Python programs I've written don't have any extension on the file name. They're intended to be commands in the system. The language they're written in is an unimportant implementation detail (and might change one day). There's usually no need to make the implementation language user-visible.

Re:Undisclosed new feature

[Kiwikwi]

In case anyone is wondering, many programs should perform better under Python 3.3 than under 3.2, due to the new way of storing Unicode strings [python.org]:

The memory usage of Python 3.3 is two to three times smaller than Python 3.2, and a little bit better than Python 2.7, on a Django benchmark.

Benchmarks that focus on certain types of string-operations have seen slowdowns, but real-world applications (such as Django web applications) should benefit from this change. (And real-world applications that perform intensive and performance critical string manipulations should use PyPy.)

One other new feature

[shutdown -p now]

It's a part of PEP 380, which is mostly about "yield from", but this little gem actually matters elsewhere. You can now return values from iterators. I.e.:

def foo():
  yield 1
  yield 2
  return 3

Since return from an iterator just raises StopIteration exception, they've added a field to propagate the value. Previously you could only use the no-argument return.

Why this matters is because it gives you the final bit needed to provide full syntactic sugar to write asynchronous functions (task-based, chained callback model - think Node.js, or Twisted in Python land) as if they were synchronous, except that you use "yield" at the points where you want to cooperatively yield control. Of course yield is the bigger part of it anyway, and it was there before, but you had to use some magic function call to implement final return. Now it really looks exactly like a synchronous function, except for "yield".