Python 3.0 Released

licorna writes "The 3.0 version of Python (also known as Python3k and Python3000) just got released few hours ago. It's the first ever intentionally backwards-incompatible Python release."

Comments

Comment removed

[account_deleted]

Comment removed based on user account deletion

Release notes

[Max Romantschuk]

The release notes might interest people:
http://docs.python.org/dev/3.0/whatsnew/3.0.html

Also note that in the end of the release notes are info on the migration path from Python 2 to 3. I'll leave the rest to people who bother to RTFA... ;)

Re:Libraries

[Yvanhoe]

Last time I checked (several months ago) it was not thought that backward compatibility would be broken very hard. Most of the modification to do should be automatic so I think that a lot of packets that are still maintained will quickly be made compatible for python 3

You got time machine!

[gzipped_tar]

The cool thing about Python is it's "time machine". In Python 2.x you can "from __future__ import " to use features scheduled for future releases. With the release of Python 2.6 there's also a "2to3" tool that will point out revisions needed for 2.x code to be 3.0-compatible, and generate patches for you.

The Python developers have been aware of the difficult road of migration long before the release of Python 3, and they did a lot of careful planning and hard work for it. One of them being the __future__ module that has been there for quite long time just for this reason.

As a Python user, my hat off for them. I wish them success heartily.

BTW: In case you don't know, there's an Easter egg in the time machine: "from __future__ import braces" ;)

Re:You got time machine!

[makapuf]

You can also use the python 2.6 "-3" option to have warnings about non future-proof constructs (ie things that can't be handled by 2to3)

in fact there are others python easter eggs :

import this
import __hello__

and ... a new one in 3.0, related to xkcd.

Re:That marks my end of use for Python

[neoform]

I'm fairly certain they got all these non-backward compatibility issues out of the way with this release so they don't have to do this kind of thing again for a long while. My guess is, they wont ever put out a non-backwards compatible release, since those changes were mostly to fix poor coding practices like being able to run certain functions without braces (e.g print "hi").

Re:Hey!

[Constantine XVI]

For the lazy (or those who don't have python installed at work):

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Re:That marks my end of use for Python

[shutdown -p now]

It's also cleanup of some stupid syntax that was there for ages. For example, exception handling. Old style:

try:
...
except (TypeError, ValueError): # catch both types of exceptions
...
except os.error, e: # catch exception and store into variable 'e'
...

New style:

try:
...
except (TypeError, ValueError): # catch both types of exceptions
...
except os.error as e: # catch exception and store into variable 'e'
...

It's fairly obvious that the latter is much clearer.

Re:Libraries

[gzipped_tar]

I just did a Google search site:scipy.org ("2.6" OR "3.0") -"ipython" -"nipy" and there are a lot of results turning up (and of course lots of bogus ones).

It seemed things are much better that I thought of. Those guys are making progress every day and my news were old news...

The difficulty with numpy/scipy is they need a great amount of C-level coding. There's 2to3 for Python code but tweaking C code is not that easy...

Re:Libraries

[Rostin]

unless the language is in the tail end of its life, like Fortran...

Fortran will continue to thrive for many years. I don't know numbers, but based on my personal experience, it's the preferred language of most computational scientists and engineers. The most recent revision occured in 2003. According to this, a new one is being worked on.

Re:Libraries

[bnenning]

But the idea of forcing that style on everyone annoys me enough to put me off of the language as a whole.

I had that exact reaction when I first came across Python. But after giving it a chance (many years later), I realized that it doesn't force a style any more than C forces the "style" of putting braces around blocks. Indentation levels are just syntax elements that happen to correspond to what most developers naturally do. Really, having to indicate blocks to the compiler in one way and to humans in another way is a DRY violation, which Python eliminates.