Slashdot Mirror
Python 2.6 to Smooth the Way for 3.0, Coming Next Month
darthcamaro writes "Some programming languages just move on to major version numbers, leaving older legacy versions (and users) behind, but that's not the plan for Python. Python 2.6 has the key goal of trying to ensure compatibility between Python 2.x and Python 3.0, which is due out in a month's time. From the article: 'Once you have your code running on 2.6, you can start getting ready for 3.0 in a number of ways,' Guido Van Rossum said. 'In particular, you can turn on "Py3k warnings," which will warn you about obsolete usage patterns for which alternatives already exist in 2.6. You can then change your code to use the modern alternative, and this will make you more ready for 3.0.'"
Why not just wait for 3.0 to make the changes? That way you'll only have to test everything once.
And if it's like some other languages you might have a long time to wait before 3.0.
But which one is correcter?
Technically the correct term would be readier, but that sounds a little awkward to some people. Generally the rule is: One Syllable=[adjective]er More than one Syllable=more [adjective] Unfortunately very few people tend to adhere to this. They usually randomly pick one method or the other, or worse, they use both. (more readier).
These kind of compatibility switches are make-or-break. I'm glad there's Python 2.6 to try to ease the problem, but Py3k means that everybody who publishes python software will all of a sudden have to maintain 2 branches, for Python 2.X line and Python 3.X line.
This isn't the same as one software package having "legacy" and "bleeding edge" branches, because that's their own choice. In this case the underlying language is forcing them to choose.
Honestly, I'm not confident in the economics of such transitions, and believe Py3k will die out.
Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.
Here are the changes.
I really have to check out the multiprocessing package. Too bad that I have to wait for the print function and the new division handling.
Technically the correct term would be readier, but that sounds a little awkward to some people. Generally the rule is: One Syllable=[adjective]er More than one Syllable=more [adjective] Unfortunately very few people tend to adhere to this. They usually randomly pick one method or the other, or worse, they use both. (more readier).
Ready has two syllables.
These changes are NOT earth-shattering. 2.6 is mostly just going to add a few new features, most important being the with statement. Most code written using Python idioms will be fine under 2.6 and 3.0. Now, if you tried to write Java-esque or C-esque code under Python, you might run into issues. Even then, I doubt it. They've been deprecating features for awhile, and 3.0 is probably the point at which they'll be yanked...you've only had a year or two of DeprecationWarnings.
I'm not sure why people whine about a language evolving. Retain backwards compatibility to a fault and you end up with C++, which is crippled by C-isms. You either know your code well enough that you could make the small incremental changes along the way, or you simply don't upgrade.
Python most needs sane standard libraries. It is far too much of a "let's throw this in there" with three different naming conventions and no package organization. It is a shame, because the language itself is pretty powerful in the right hands.
What Python features broke for you between minor releases?
I find it pretty hard to believe any Python user would actually switch to Perl, and stick to it.
You sir, are probably making this story up :-)
Reading the release, they have decided to really push 16-bit strings (they call this "Unicode" but it really is what is called UTF-16). I think this is a serious mistake.
The proper solution is to use 8-bit strings, but any functions that care (such as I/O) should treat them as being UTF-8. Most functions do not care and thus the treatment of "Unicode" and "bytes" are the same.
The problem with UTF-16 is you cannot losslessly convert a string that *might* be UTF-8 to UTF-16 and then back again. This is because any illegal UTF-8 byte sequences will be lost or altered. This is a MAJOR problem for code that wants to process data that is likely to be text but must not be altered under any circumstances, in effect such programs are forced to be ASCII-only, even though UTF-8 is purposly designed so that such programs could display all the Unicode characters. Note that bad UTF-16 (ie with mismatched surrogate pairs) can be losslessly converted to UTF-8 and back.
This has been a real pain so far in our use of Python, and I am quite alarmed to see that they are changing the meaning of plain quotes in 3.0 to "Unicode". This is really a serious step backwards, as we will be forced to tell anybody using our system to put 'b' before all their string constants and I suspect there will be a lot less automatic conversion of these strings to unicode when we want to display them. Note that Qt is also causing a lot of trouble here too.
You can keep your code compatible with both at the same time. Deprecated features are trivial to rewrite in most cases. There are even tools for this.
Most distros already include the current and previous versions of Python. So Ubuntu, for instance, will include 2.6 and 3.0, and possibly 2.5 as well.
Furthermore, you can check to see what version of Python you're running under and make your code so that it accomodates both. This is all accessible via sys.version or sys.version_info
>>> sys.version
'2.5.1 (r251:54863, Jul 31 2008, 22:53:39) \n[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)]
>>> sys.version_info
(2, 5, 1, 'final', 0)
With that knowledge, you just put all your version specific stuff in modules.
So you can do a:
import sys
major,minor,micro,release,release_num = sys.version
if (major > 3):
import module_for_python_3.0
else:
import module_for_python_2.x
My blog
Many essential third party libraries need to be converted for Python 3.0. I need M2Crypto (SSL support) and MySQLdb (MySQL support), neither of which is ready for Python 3.0, and neither of which has been updated in the last year or so.
My guess is that it will be three years before stock mainstream Linux distros come with Python 3.0 and a set of libraries that work with it.
GP missed an important part of the general rule: adjectives that end with "y" form the comparative with "ier" even if they are two syllables. Uglier, happier, prettier, etc.
Anthony Baxter gave a pretty good talk on the implications at LCA 2008 earlier this year.
http://video.google.com/videoplay?docid=4264641260805367198&hl=en
"Everything is adjustable, provided you have the right tools"
3.0rc1 (beta) is already available and has been for some time now. The advantage of 2.6 is not as much its backward-compatibility but its ability to tell you exactly what needs to change (via runtime warnings) for 3.0 without actually breaking your code. I've been using both for months now, so this article isn't exactly hot news.
I like Python for a whole lot of other reasons too. I am a programming language snob. I used to write device drivers in C, I respected the power of the language and how unforgiving it was. My first reaction to Python was "layout is part of the language? Ha!". But credit to me, I tried it out properly, and fuck me, it's fun! I needed to carry out some very repetitive operations on a web-interace and naturally I didn't want to spend hours clicking buttons on a website. I thought to myself, I wonder how hard it is to manage cookies in Python. About forty minutes later I had a flexible and working Python script which was carrying out all my actions for me. And the forty minutes was mostly writing supporting code to compute the appropriate actions to send to the URL.
Python, is quite simply, great. You only have to read from say, the Python Cookbook, to get a feel for how much thought has gone into the design of the language. I'm still a programming language snob, it's just that I found Python was well worth being proud of using.
(Mind you, there online documentation could be better - PHP's site for example, is so much friendlier).
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
Microsoft and lots of other proprietary software companies does that all the time... :)
This trolling problem is getting out of hand. I really think that we should consider banning suspect IP ranges and proxies. Near half of this page is trolling. It's making reading real comments prohibitively difficult, especially with people responding to -1 posts.
For whatever reason, people fail to understand python natively supports parallel installs.
But some popular environments (Windows, Mac, shared web hosting) identify scripts not by their script magic but instead by their file extension. When I used Google to search for python parallel install windows, I got a whole bunch of results about parallel ports and parallel processing. Does a parallel install work in Linux, Solaris, *BSD, and the like, or is there a recommended way to use it with more popular desktop operating systems such as Windows and Mac OS X? And how do parallel installs interact with web hosting?
Another common pattern to use for this, as well as for libraries, is the following:
try:
import one_way_to_do_it
except:
import more_common_way_to_do_it
But how well does a try block work with things that depend on from __future__ statements that Python 2.5.x doesn't recognize, such as the different print syntax and the different string literal syntax ("8bitchars", u"32bitchars" vs. b"8bitchars", "32bitchars")? From Python 2.5.x's definition of a future statement:
This appears to exclude try statements.
So don't use Python 3.0.
That woul dbring the same problems as the transition from PHP 4 to PHP 5. How would I deploy my product to end users who have installed Python 3.x as the system-wide handler for .py files? Will Python Software Foundation recommend the use of an extension such as .py2? Conversely, if I do take advantage of Python 3.x, how would I deploy to end users who still use 2.x?
The problem with UTF-16 is you cannot losslessly convert a string that *might* be UTF-8 to UTF-16 and then back again. This is because any illegal UTF-8 byte sequences will be lost or altered.
Then set strict conversion, which will raise UnicodeError for any nonconforming byte sequences. My problem with UTF-16 is how it bloats in-memory databases of mostly-ASCII text by a factor of nearly 2 (or 4 if Python is compiled with UTF-32 to handle hieroglyphics and ancient Chinese).
They're actually hard at work on that problem too. In addition to Python 2.6 being released, the Python documentation is now generated using Sphinx. See for example the new tutorial output. Big WTF the first time I saw it, but it's a decent improvement with more in the pipeline.
This sig is intentionally left blank
There seems to be a massive increase in trolling recently.
I will say the same thing that plagues python has plagued Java and probably hosts of other platforms.
Java? Some things have been broken occasionally in newer releases if you're doing stuff that's exotic enough, but in general I'd say that Java has been pretty damn backwards-compatible all the way. Save for those odd bugs, things written and compiled for Java 1.3 tend to run pretty niftily on 1.6.
So, if your code requires Python 2.5, you could just have "#!/usr/bin/env python2.5" at the beginning of your script, and it would be run using the python2.5 command.
Is there a way to get Windows Explorer or Apache mod_python to follow the #! line instead of the .py extension?
Don't mod something down just because you disagree. When I have mod points, I never downmod things out of disagreement. This is a legitimate concern over the python strategy. They have benefited from their flexibility (the language at a given instant I will give is relatively low on quirks as they are rethought and replaced, whereas perl is chock-full of quirks that you must learn to live with), but there is a price.
Nothing is perfect. Nothing is without flaws. To achieve one end, something almost always is given up. Don't mod a post down because it points out what was given up to achieve an impressive advantage.
XML is like violence. If it doesn't solve the problem, use more.
Please explain. If you used DBAPI standard interfaces, it's unlikely anything you were using broke or changed. Most DBAPI packages do a pretty good job (all I've seen) of explaining which interfaces comply with the DBAPI spec and which interfaces don't. My guess is you didn't pay attention. That's a coder problem, not a language problem.
Thats more to do with PHP having excelent documentation than Pythons being poor.
I do agree the formal stuff is a bit terse, but once you've mastered the tutorial, most of pythons really just working out the modules, and they tend to be pretty well documented.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
"Troll" for THAT comment? Man, somebody does not know what "troll" means!
Nothing I can do about it but bitch, but my bitch is legitimate.
NEWS, modders: disagreement does NOT automatically equal "troll".
No. You can go on all you want about "needed to change" and "autofix" and etc, but the bottom line is that this code presently isn't broken, and I am not about to fix code that isn't broken. It makes no sense on any level; financially, time-wise, or strategically. I have better things to do than refactor my code for entirely arbitrary reasons. Perhaps I just place a different value on my time than you do; that's fine. You should, of course, feel free to do whatever you like.
I've fallen off your lawn, and I can't get up.
Request a government bailout for being dumbasses and hosting on windows?
Shared Linux hosting also has problems with different versions of an interpreter. I didn't see anything in the mod_python manual about ability to select an interpreter based on the #! line. I've changed the subject line to clarify.