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.'"
because of that
Because the development cycle is longer than that for derivative projects. Imagine if you could have a cycled and tested app that was ready from day 0...
Hire me...
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 :-)
It's because all their old code breaks. And that hurts.
Honestly, I'm not confident in the economics of such transitions, and believe Py3k will die out.
Why would Python 3.0 'die out'? Even if you don't believe existing projects will make the switch there's no reason why new projects won't want to have the considerable benefits of using Python 3.0.
No, they don't "have to" maintain two branches. They can choose to, or they can maintain one (which depends on their particular circumstance); if necessary (if it is an app and not a library) they can just distribute the right interpreter with the app.
Yeah, actually, it is exactly the same as that, at least as long as bug-fixes and maintenance continues on Python 2.x: the "one software package" being the Python interpreter.
And, yeah, if those maintaining python-based projects choose to maintain Python-2.x and Python-3.x based versions, that will also be an instance of exactly what you say it wouldn't be, as it will still be their own choice.
So don't use Python 3.0. If it's critical, you're not upgrading from a known working base anyways, right? And if it's not, this will hold your hand.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
Every once in a while we see one of these "brainstorms"; for example, Microsoft pulled VB from the office suite... only to put it back. Because the idea was stupid; there was a ton of production code / applications they flat out broke. Python's doing exactly the same thing, and it's not going to work out for the same reason(s.)
If you're going to modify a language, you *must* do it in a compatible manner, otherwise what you're doing is making a new language that will require an entirely new community. Names notwithstanding, and resemblance beyond incompatibilities notwithstanding.
I've fallen off your lawn, and I can't get up.
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.
For whatever reason, people fail to understand python natively supports parallel installs. Furthermore, since python's preferred script magic is "#!/bin/env python", rather than, "#!/bin/python", the executing script will use the python that it finds in your path. Additionally, you can also tie python to a specific version as "python2.5". Want a different python? Change your path. A script requires a specific version of python? Change the script to require it. It's one line and trivial. It's at the top of the file, so there's no hunting even.
New python releases only pose problems for the uninitiated, the ignorant, or the dumb.
People expect a string to be a sequence of characters. Please notice the first word in that sentence.
"People" are not computers. "people" LOOK at the display. People are not trying to copy the data literally from one place to another or do comparisons of strings or read files that might (horrors) not contain correct UTF-8 data. There is no reason to mangle the data until the very last moment before it is put on the display.
I can quite confirm that if you have more than one way to represent the same sequence (such as different ways of producing the same UTF-8 error) you will produce a MAJOR screw up, quite likely an exploitable security hole. It also is not nice if "copy" mangles data just because it had a sequence that could not be coinverted correctly to glyphs.
I think the lesson is that there is ONLY byte sequences.
The fact that some code can interpret that byte sequence and draw something on the screen that the user thinks of as "text" is completely irrelevant and should not be a fundemental datatype of a programming language. This should be part of the code that draws the text. Imagine if every other type of data, such as image pixels, or sound samples, had a different IO routine and you could never read a file with the wrong routine because the conversion was lossy.
The real problem is that everybody's mind has been polluted by decades of ASCII where there was no difference between characters and bytes. All I can suggest is to try to think of text as words or sentences. Nobody would suggest that it would be good to make all words use the same amount of storage, or that it is important that you be unable to split a string except at word boundaries. But there has been so much use of ASCII that people think this is important for "characters".
I also believe there is a serious politically-correctness problem. Otherwise logical programmers are consumed with guilt because Americans get the "better" short encodings, and therefore feel they have to punish themselves by making the conversion to i18n as painful as possible so that Americans have just as much trouble as anybody else. The fact that they have actually made I18N far harder for everybody and thus actually discouraged it is the ironic result of this guilt.
The proper solution is to do what they did: hide from the programmer what internal format is used for strings. The only time programmers should know about the encoding is when they themselves explicitly select an encoding so that they can turn a bunch of bytes into a string or when they're sending the string out into the world as a bunch of bytes. Encode and decode explicitly at the edges. Internally, hide the implementation details. It's just basic OO.
Uh, it's almost exactly the opposite of what you're saying. You don't have to have a Python 3.x line; you can just deploy your code on Python 2.6, keep your working application working, and do all your new development and testing with Python 3.x warnings turned on. Then your next release is Python 3.0 compatible; or if you somehow fail to do finish the Python 3.x upgrades in time for your next release, you don't have to release on Python 3.x, you can just keep using Python 2.6 even though your code is partially upgraded.
Partially upgraded codelines are always the problem with major version upgrades, and the Python 2.6/3.0 future compatibility is designed precisely so that this problem is not a problem.
Python has bent over backwards to make the upgrade as easy as possible for people with serious Python applications in production.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Changing my path is not practical. It's too broad. I'd have to write a shell script wrapper for the application which did 'env PATH=new_python:$PATH the_real_application "$*"' or something. And it's not just me; I'd have to communicate this to all other users of the system somehow. And changing one line of a script is not trivial, if I'm not root.
All this may seem like minor things, but it adds up. And no other good language puts me in situations like that.
Or those of us who have been around for a while, and seen innocent backwards-incompatible changes become maintenance nightmares ...
Ok, maybe not a nightmare in this case, but an inconvenience and annoyance which
will keep being inconvenient and annoying for years, until the last Python 2.x dependency
goes away.
The best way to judge this would probably be to look at what Linux distributions like Debian want to do about Python 3.0. They ship one Python as the default (2.4 currently, for Debian) but provide others too. I bet even a change from 2.4 to 2.5 is a major migration for them.