This post originated from an RSS feed registered with Web Buzz
by Douglas Clifton.
Original Post: Python 2.6
Feed Title: blogZero
Feed URL: http://loadaveragezero.com/app/s9y/index.php?/feeds/index.rss1
Feed Description: Web Development News, Culture and Opinion
For someone with many moons of writing code in C and C-like languages, making the transition to Python was indeed a paradigm shift. But we're only human and as humans it's natural to be resistant to change. For instance, when I first started to study Python in earnest I found the notion of indentation as syntax rather odd. And where oh where are my parenthesis? What's this, no line termination semicolons? No curly braces around blocks of code? This is insanity!
A Bit of History
Of the five programming languages I refer to most often, Python stands out as being unique in many regards. It's interesting to compare and contrast the why and the how they were developed—and by whom.
C (and its descendants) ca. 1970 — the oldest of the four, developed by computer scientists at Bell Labs during the early stages of the evolution of Unix
Perl ca. 1986 — developed by a lingust turned system administrator (now a researcher and developer at O'Reilly).
Python ca. 1990 — developed by a mathematician turned programmer (now working at Google).
PHP ca. 1995 — developed by a systems design engineer turned programmer (now an infrastructure architecture engineer at Yahoo!).
Last month brought Python developers a step closer to the up-and-coming version 3.0, with the final production-ready release of Python 2.6. It adds plenty of new features, modules, improvements and bug fixes. For the Python 2.6 and 3.0 release schedule, visit PEP 361.
So what's the big deal? Developers are both excited and concerned—3.0 promises to bring great things—but Guido has made it clear that the new version will likely break some older scripts. It reminds me of PHP 4.x to 5, although, at least for me, the impact was minimal. And version 5, once it stabilized, was a big improvement in terms of OOP.
By adding compatibility functions in the future_builtins module, and a -3 switch which warns about usages that will become obsolete, Python 2.6 should mitigate the migration to version 3.0.