The Python Software Foundation releases Python 3.0 on Dec. 3, the latest version of the Python dynamic language for application development. This versions comes with several new features.
This last version (a.k.a. "Python 3000" or "Py3k"), is a new version of the language that is incompatible with the 2.x line of releases --Python Software Foundation officials said.
According to the PSF, with Version 3.0 the Python language is mostly the same, but
many details, especially how built-in objects such as dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places, foundation officials said.
In a blog post about Python 3.0, Van Rossum (the creator of the Python language) said that there are more changes than in a typical release, and more that are important for all Python users. He gives as well some example changes like the print function:
The print statement has been replaced with a print() function:
In a blog post about Python 3.0, Van Rossum (the creator of the Python language) said that there are more changes than in a typical release, and more that are important for all Python users. He gives as well some example changes like the print function:
The print statement has been replaced with a print() function:
Old: print "The answer is", 2*2
New: print("The answer is", 2*2)
Old: print x, # Trailing comma suppresses newline
New: print(x, end=" ") # Appends a space instead of a newline
Old: print # Prints a newline
New: print() # You must call the function!
Old: print >>sys.stderr, "fatal error"
New: print("fatal error", file=sys.stderr)
Old: print (x, y) # prints repr((x, y))
New: print((x, y)) # Not the same as print(x, y)!
In a blog post from March, Van Rossum warned Python developers: "Don't change your APIs incompatibly when porting to Py3k."
He added:
Yes, you heard that right: even though Python 3.0 is changing incompatibly, I implore you (especially if you're maintaining a library that's used by others) not to make incompatible changes to your API. If you have make API changes, do them before you port to 3.0—release a version with the new API for Python 2.5, or 2.6 if you must. (Or do it later, after you've released a port to 3.0 without adding new features.)
Explaining a bit further, Van Rossum said, "Why? Think of your users. Suppose Ima Lumberjack has implemented a Web 2.0 app for managing his sawmill. Ima is a happy user of your most excellent Web 2.0 framework. Now Ima wants to upgrade his app to Py3k. He waits until you have ported your framework to Py3k. He does everything by the books, runs his source code through the 2to3 tool, and starts testing. Imagine his despair when the tests fail: How is he going to tell whether the breakage is due to your API changes or due to his own code not being Py3k-ready?"
Yet, "On the other hand, if [you] port your Web 2.0 framework to Py3k without making API changes, Ima's task is much more focused: The bugs he is left with after running 2to3 are definitely in his own code, which (presumably) he knows how to debug and fix," Van Rossum said.
He added:
Yes, you heard that right: even though Python 3.0 is changing incompatibly, I implore you (especially if you're maintaining a library that's used by others) not to make incompatible changes to your API. If you have make API changes, do them before you port to 3.0—release a version with the new API for Python 2.5, or 2.6 if you must. (Or do it later, after you've released a port to 3.0 without adding new features.)
Explaining a bit further, Van Rossum said, "Why? Think of your users. Suppose Ima Lumberjack has implemented a Web 2.0 app for managing his sawmill. Ima is a happy user of your most excellent Web 2.0 framework. Now Ima wants to upgrade his app to Py3k. He waits until you have ported your framework to Py3k. He does everything by the books, runs his source code through the 2to3 tool, and starts testing. Imagine his despair when the tests fail: How is he going to tell whether the breakage is due to your API changes or due to his own code not being Py3k-ready?"
Yet, "On the other hand, if [you] port your Web 2.0 framework to Py3k without making API changes, Ima's task is much more focused: The bugs he is left with after running 2to3 are definitely in his own code, which (presumably) he knows how to debug and fix," Van Rossum said.
How to encourage this blog if you like it:
- Promote our sponsors;
- Add any kind of comment or critic;
- Ask me directly by email if you prefer.
I am 
