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.'"

Comments

tough transitions

[AceJohnny]

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.

Re:tough transitions

[imbaczek]

it'll take several years, but a critical mass will switch eventually IMHO.

Re:More ready?

[Anonymous Coward]

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.

Cut the crap.

[Anonymous Coward]

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.

Re:Cut the crap.

[Anonymous Coward]

Well I'd guess you'd be in for a fair amount of digging if you want it to run on 3.X and you aren't using unicode for your text strings yet.

String f**k up

[spitzak]

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.

Re:String f**k up

[spitzak]

No, think a little harder.

Imagine a file system that names the files with strings of bytes.

It is absolutely vital that if I ask for a list of files and then try to open them, that this all work, no matter what byte sequence has managed to get in there as a filename.

It is also *nice* but nowhere near as vital that I be able to show these names to users and they read them as Unicode strings.

Re:String f**k up

[spitzak]

You might not be aware of this, but computers are used for more than just transmitting text. I don't want my binary streams being rewritten to gibberish because some I/O routine was written to be too clever

Thank you for explaining exactly why I want UTF-8 to be used, while thinking you were arguing against it.

Data is NOT just text. Therefore we should not be mangling it because we think it is text. We have enough trouble with MSDOS inserting \r characters. This crap is a million times worse.

Re:String f**k up

[spitzak]

Spoken like somebody that's never had to deal with encoding issues. Using UTF-8 internally is fine, but exposing it to the programmer is insane and error-prone. And if the programmer then proceeds to manipulate that raw byte buffer as a string, he's an idiot.

The compiler will turn "unicode" into the utf-8 encoding. The programmer does not see \xnn sequences of the utf-8 bytes. Try some modern compilers with utf-8 support some day before you say anything stupid again.

Any programmer that modifies UTF-16 as a raw array of words is an idiot. Besides surrogate pairs, there are combining characters and bidirectional indicators and lots of other trouble. In fact I prefer UTF-8 exactly because it discourages such misuse of strings, which are really made of words, sentences, etc.

If you try to convert bytes that aren't in UTF-8 using a UTF-8 codec, an error will be raised. This behavior is proper -- if you don't know what format your input is in, there's no way to perform text-based operations on it.

You have just introduced a massive DOS hole into your programs. Or do you really think you should run a "is this correct UTF-8" call before any attempt to convert? Sorry, it is not going to raise an error, it will instead convert to error UTF-16 characters.

Every developer I know uses Unicode strings already. The new behavior is just one less character to type in front of literals.

You know that Python will convert your bytes from UTF-8 to "Unicode" automatically when needed? No you didn't? Might want to study up on that...

Otherwise said as: "We're too stupid to fix the glaring encoding errors in our product

The encoding errors are not in our product. They are in the files we are attempting to read (metadata attached to images, mostly). Dumbass

Re:String f**k up

[Anonymous Coward]

The number of "characters" is completely useless.

Whawhawhaaaat? It is useless to know how many characters are in a string, but usefully to know the size the string takes in memory in a completely memory-managed language?

Either you are exaggerating excessively (to prove your point, I posit charitably?), have an extraordinarily insular view of the programming world, are a troll, or, I think most likely, are an intelligent and thoughtful programmer the midst of temporarily insanity brought about by becoming entrenched fallacy defending a losing argument.

Take a deep breath...No, really. Do it. Breath in....wait a moment....and out.

All of Slashdot has pounced on your message, is arguing against you, and insulting you. It's because we're jerks. Also there's a technical problem in a few of your comments, but mostly we're just jerks. Take a night off, cool off, remember that we are jerks and the insults are not really directed at you, admit to yourself that there were mistakes in your argument, learn from them, and move on.

Ahh, and I just realized why you care about the size a string takes in memory. You are doing IO and are trying to use a string to store non-text data. Don't use a string. Use the bytes type instead.

Not really

[widman]

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.

Doesn't matter

[morgan_greywolf]

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

Old news...

[pdxp]

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.

Re:i like python

[h4rm0ny]

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. :D

(Mind you, there online documentation could be better - PHP's site for example, is so much friendlier).