Weekly Edition
Return to the Development page
| |||||||||||||
What's new in Python 2.6
Andrew Kuchling has done his usual top-quality job in the recently-posted
What's New in
Python 2.6 document. "The major theme of Python 2.6 is preparing
the migration path to Python 3.0, a major redesign of the
language. Whenever possible, Python 2.6 incorporates new features and
syntax from 3.0 while remaining compatible with existing code by not
removing older features or syntax." Required reading for any Python
programmer.
(Log in to post comments)
Missed a spot? Posted Sep 2, 2008 5:41 UTC (Tue) by mikachu (guest, #5333) [Link]
"The net result of the 2.6 optimizations is that Python 2.6 runs the pystone benchmark around XXX% faster than Python 2.5."
Missed a spot? Posted Sep 2, 2008 8:00 UTC (Tue) by jamesh (guest, #1159) [Link]
IIRC, previous pre-release "what's new" documents only listed an XX% improvement over the predecessor version. So I guess 2.6 will be quite impressive.
Missed a spot? Posted Sep 2, 2008 8:17 UTC (Tue) by qg6te2 (guest, #52587) [Link] This must be placed in context though: when compared to a language such as C++, Python is still quite slow for non-trivial things or things straying outside of the functionality present in C based modules. For real speed-ups a tool like Shed Skin is required.
Missed a spot? Posted Sep 2, 2008 11:38 UTC (Tue) by MathFox (guest, #6104) [Link]
Python allows me to code the functionality I need three times as fast as C++... for a small runtime speed penalty. My programs are largely I/O bound (and use dynamic typing at places... which will tie Shed Skin in a knot.)
Missed a spot? Posted Sep 2, 2008 20:09 UTC (Tue) by drag (subscriber, #31333) [Link]
There is already Pyrex and Cython (a friendly fork of Pyrex that adds more features) for making optimized modules for Python.
http://wiki.cython.org/FAQ
So that stuff is more mature.
But simply taking Python, translate it to C++, then compile optimized binaries is a pretty damn neat trick.
What I am curious about, however, is how well shedskin works for programs that heavily use Python modules. Since Python is largely worthless, for it's current typical usage, without heavily relying on modules.
Missed a spot? Posted Sep 5, 2008 9:18 UTC (Fri) by srepmub (subscriber, #47230) [Link]
Currently, about 15 standard library modules are supported, such as re, math, random, collections and getopt. More will certainly follow (e.g. we have a datetime implementation in SVN), but this is a slow process, and it will always be limited to a relatively small subset of the standard library.
However, I don't think this is a really big problem in many cases, because in principle you can always generate extension modules ('shedskin -e'). This way, you get a potentially massive speedup for one or more speed-critical parts, while still being able to use arbitrary Python modules and dynamic constructs in the 'main' program. And everything is still in pure Python :)
Note that I don't think Shed Skin is the ultimate solution to improve Python performance. It's a cool toy that may be useful in certain cases, but what we really need is a good JIT, something that may come out of the PyPy project.
Mark Dufour (Shed Skin main author)
What's new in Python 2.6 Posted Sep 2, 2008 11:46 UTC (Tue) by MiguelAtWork (guest, #53380) [Link] I love Python, but I really wish they would fix a couple of annoyances:
What's new in Python 2.6 Posted Sep 2, 2008 13:14 UTC (Tue) by jamesh (guest, #1159) [Link]
Most new modules follow the PEP 8 naming guidelines, and some of the Python 3.0 compatibility breaks are to fix up naming of old modules.
As for adding new builtins, that doesn't break old code. If you name a variable "next" in a function, the only problem you'll have with 2.6 is an inability to call the next() builtin from that function. The code will continue to work as before.
Now introducing new keywords to the language is another matter. The "with" keyword is the main one for 2.6, but developers had warning about that since 2.5 was released. Also, some keywords have been introduced such that they are only reserved in certain parser contexts (where this can be done unambiguously), allowing you to continue using them as variable names. They Python developers take this quite seriously.
What's new in Python 2.6 Posted Sep 3, 2008 11:43 UTC (Wed) by MiguelAtWork (guest, #53380) [Link] I hadn't read PEP 8 before and I found it interesting, but it doesn't seem to help much with consistency in the use of underscores. New functions in 2.6 include such names as namedtuple, isgeneratorfunction or methodcaller on the no-underscores front, and ignore_patterns or create_connection on the other side. This still seems fairly random to me.As for the comment about "next", I was thinking of code like this:
def old_function():
global next
next = "Hi!"
# ... 1000 lines of code here ...
def new_function(it):
value = next(it)
I believe this would fail.
What's new in Python 2.6 Posted Sep 3, 2008 13:10 UTC (Wed) by amk (subscriber, #19) [Link]
Regarding the 'next' example: Yes, that code would crash, but that's not breaking *existing* code; you would have to add new code that used the next() built-in, and that would simply be a coding error. Existing applications that happen to use 'next' as a variable name should be OK.
What's new in Python 2.6 Posted Sep 3, 2008 16:16 UTC (Wed) by MiguelAtWork (guest, #53380) [Link]
I know, sorry I wasn't clear. The situation I was thinking of is one where you're updating an application written before 2.6 but you're unaware that the application redefines e.g. next. I don't think that's too far-fetched.
What's new in Python 2.6 Posted Sep 4, 2008 2:28 UTC (Thu) by jamesh (guest, #1159) [Link]
Assuming that the code has been broken up into reasonable sized modules, this isn't usually that big a deal. You can tackle the "Python 2.6 cleanness" problem on a module by module basis. A global next variable/function in one module isn't going to shadow the builtin in other modules.
|
|||||||||||||