The Evolution of Python 3

chromatic writes to tell us that O'Reilly has an interview with Guido van Rossum on the evolutionary process that gave us Python 3.0 and what is in store for the future. "I'd like to reiterate that at this point, it's a very personal choice to decide whether to use 3.0 or 2.6. You don't run the risk of being left behind by taking a conservative stance at this point. 2.6 will be just as well supported by the same group of core Python developers as 3.0. At the same time, we're also not sort of deemphasizing the importance and quality of 3.0. So if you are not held back by external requirements like dependencies on packages or third party software that hasn't been ported to 3.0 yet or working in an environment where everyone else is using another version. If you're learning Python for the first time, 3.0 is a great way to learn the language. There's a couple of things that trip over beginners have been removed."

Re:Probably not an issue for beginners?

[morgan_greywolf]

Unless you're trying to learn how to code Django apps, which won't work on Python 3.0. Neither will a lot of other 3rd party modules.

Re:Probably not an issue for beginners?

[Random BedHead Ed]

Not really. Keep learning 2.x as you were. Quoth Guido:

http://www.artima.com/weblogs/viewpost.jsp?thread=211200 [artima.com]

Ignore 3.0 for now. If you encounter it, there is a handy script to help update your code, though most of the language is unchanged. The biggest gotcha is that print is now a function print() rather than a statement.

Re:Im working on a Python clone

[LighterShadeOfBlack]

The name Python originally came from Monty Python, so you're about 18 years late on that joke.

Getting into Python 3

[dedazo]

For those interested, IBM is running a primer series [ibm.com] on the new language/runtime features.

There's also this [python.org] older (but still relevant) PEP that explains things that did not change between the 2.x series and 3.0.

Personally, I'm not looking forward to migrating existing code bases (especially non-trivial ones) to 3.0, but I'm planning to do all new development against it (of course assuming that the various packages I use have ports).

For Python trivia lovers, here [slashdot.org] the the actual moment in time when 3.0 was let loose on the world. I'm such a sentimental geek :)

Re:Are distributions going to permit both at once?

[joe_cot]

I currently have both python2.4 and python2.5 installed in Ubuntu. They're different packages, and can easily be installed alongside each other.

For distributions with dependency management (Ubuntu, Debian, Fedora, any modern distribution), this isn't a hard issue -- in the distros I'm familiar with (Debian/Ubuntu) the different versions of python are just separate packages, apps have a list of dependencies and can list that they depend on a certain version of python, and the python package is just a dummy package that "depends" on the latest version of python.

The same thing is done with different versions of Java, GTK, etc. When a toolkit or language makes a huge backward-incompatible change, it's rare that they can't just be installed alongside each other. Different 2.x versions of Python work just fine alongside each other, and I don't see how Python 3 would be any different.

Re:In all seriousness

[AlexMax2742]

There is a standard [python.org]

Re:Unicode

[omuls are tasty]

I've read your previous posts. You weren't making any sense back then, and you aren't making any now either. However, for some reason your trolling seems to go well with the mods every time.

It's a fact that the Unicode support in Python is not perfect (see e.g. this post [cmlenz.net]). However, every and any issue you might have with Python 3 internal representation of Unicode strings, you are bound to have with Python 2 as well. The only thing that has changed is that the unicode and str types got replaced with str and bytes types respectively, and that you can't mix the two anymore without explicitely encoding/decoding them. And both of these are good things (TM).

Also, for someone who has supposedly spent so much time investigating Python Unicode support to great depths, it's rather funny that you don't know that Python does not use UTF-16 for internal representation of Unicode strings. It uses either UCS-2 (the default) or UCS-4, which are both fixed-length encodings. Unfortunately, the default one cannot represent characters outside the Basic Multilingual Plane, but hey - neither can say Java.

And finally, your argument that "real Python programs need to handle arbitrary data that is *PROBABLY* UTF-8." is utter rubbish. If you need to handle non-ASCII textual data you either:

1. need to know the encoding of the data explicitely (say an HTTP header, or just a general convention) OR
2. need to perform heuristics on the data and try to guess the encoding 0 and then hope for the best