Python 3.0 To Be Backwards Incompatible 438
Stony Stevenson writes "Organizations using Python will be affected in a major way by changes in store for the language over the course of the next twelve months, Linux.conf.au attendees were told this morning. The Python development community is working towards a new, backwards-incompatible version of the language, version 3.0, which is slated for release in early 2009. Anthony Baxter, the release manager for Python and a senior software engineer at Google Australia, said "We are going to break pretty much all the code. Pretty much every program will need changes." Baxter also added another tidbit for attendees, saying that Python accounts for around 15 percent of Google's code base."
Another Shock Story (Score:5, Informative)
print as function vs. keyword (Score:5, Informative)
print "This used to work"
You now have to do
print("This is how 3.0 rolls")
There will be no grandfathering, so everything needs to be refactored accordingly.
A small, but significant change.
Re:Workaround... (Score:5, Informative)
Almost 2 years old? (Score:5, Informative)
- Python 3 (or Python 3000 as it was called) as a serious effort is more than a year old.
- There is already a working interpreter in its second alpha release.
- Final release is slated for August. (No infinite Perl 6 development.)
- Developers are working very hard to make the 2 to 3 transition as painless as possible.
- The Python team is committed to keeping the 2.x series going until 3.x has clearly been accepted.
You may now proceed to complain having been thus informed.For more info, check out (Score:5, Informative)
http://docs.python.org/dev/3.0/whatsnew/3.0.html [python.org]
Not news in any way (Score:5, Informative)
This has been known for donkey's years. Guido has been talking about this compatibility break since the 90s. The changes were laid out in detail in PEP 3000 [python.org], first published in 2006. They have already released two alphas. A conversion tool to automatically make some of the required changes (such as changing print statements to print() function calls) already exists [python.org].
in fact, such a utility already exists (Score:5, Informative)
And, as others have stated, there'll be the 2.6 branch, which will be backwards compatible.
Or, in other words, the story is stupid and misleading.
Re:Just rename it. (Score:5, Informative)
The vast majority of the language and standard library will remain the same. This is just about tidying up some unfortunate warts that affect a lot of people, such as unifying the different string types. It remains Python in practically every way, and renaming it is simply unnecessary.
Re:print as function vs. keyword (Score:5, Informative)
Actually, the migration tool 2to3 performs this change automatically, and the function call approach works in both 2.5 and 3.0, so the incompatibility is greatly exaggerated.
Re:Damn right (Score:2, Informative)
Or does Ubuntu launch things based on file extensions?
Re:Another Shock Story (Score:1, Informative)
If anything its a long term upgrade path, not some "OMG EVERYTHING WILL BREAK NEXT YEAR" type crisis.
Re:It's a race (Score:3, Informative)
No. [programmersheaven.com]
Re:#1 way to prevent adoption of new language vers (Score:5, Informative)
First of all, the changes are mostly simplifications to the core language (e.g., how to catch exceptions is currently a bit of a mess if you want to catch more than one exception). So for example, range and xrange are now one, iterators become more prevalent, "old-style" classes are going away and so new-style ones will become the standard, a lot of the things that have been deprecated now are being removed, etc. It isn't really a "new language" in any sense. This is far superior to Java's "always backwards compatible" approach which has lead to a lot of cruft building up over the years.
Next, it needs to be understood that 2.6 will be backwards compatible and include a warnings mode to highlight things that won't work in Python 3.0 to ease in the transition. There should be no problem supporting both on one system.
Finally, they are providing a 2.5->3.0 translation tool that runs in 2.5 and does most of the mechanical translation between the two for you.
Re:Another Shock Story (Score:3, Informative)
It's been a lot longer than two years. For example, see this thread [google.com] from eight years ago:
And from a reply:
Python takes a step backwards. (Score:3, Informative)
There's surprisingly little in Python 3.x that's really needed, and much that isn't. The approach to parameter typing (optional and unenforced) is silly. Having it and not enforcing it is just asking for trouble.
It probably would have been more productive to standardize on 2.6 and get a formal standard out the door, instead of using the CPython implementation as the standard. With a formal standard that couldn't be casually changed, the other implementations, all of which are faster than CPython, would have a firm target to implement. Python is twenty years old, and there still aren't multiple, compatible implementations.
Python could be a much higher performance language. Take a look at the Shed Skin implementation. One guy is trying to implement a hard-code compiler for Python that does type inference to determine types at compile time whenever possible. That yields a 10x-30x speedup. If you have rackmount servers running Python, that's a big win - one rack instead of ten.
Python has some optimization gotchas that really should be fixed. The big problem is "undetectable dynamism", or "if the only tool you have is a dictionary, everything looks like a hash". It's rare to store into a local variable of a function, or modify a method of a class from the outside of the class. Most classes don't have attributes added to them after creation. Python allows all these things, which can occasionally be useful. The trouble is that it's really tough to tell at compile time if the hard cases are going to be needed, and thus code has to be pessimized for the worst case.
This could be fixed with a few restrictions:
- Classes which can be dynamically modified from outside themselves should be subclasses of "dynamicobject" instead of "object". This makes everything dynamic but reduces performance. For most objects, the compiler can then find all the variables during
compilation, assign them fixed slots, and avoid having a dictionary in each object.
If an object indulges in self-modification or attribute creation, the compiler can see that at compile time and generate the slow code for the hard case. This is only needed for objects which are patched from outside themselves, something the compiler can't now detect and needs to know about.
- Variables cannot change major type during execution. If a variable is initialized with an integer or float value, it cannot thereafter be changed to an object type. Shed Skin imposes this restriction, which means it doesn't have to "box" numbers in objects and can hard-compile arithmetic.
This would make it possible to boost Python performance up to the Java level, and get it within striking distance of C/C++, yet not require declarations.Re:Just rename it. (Score:2, Informative)
Further more, if you don't already know that, why are you posting?
Re:It's a race (Score:5, Informative)
> Will I be able to convert my Perl 5 programs to Perl 6?
> Yes. Larry Wall and others are already working on a Perl 5 to Perl 6 translator, which will be able to translate (most) Perl 5 source code to the equivalent Perl 6 syntax.
> In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the compiler to directly execute any code that it recognizes as being written in Perl 5.
Depending on who you talk to, this can be said to be backward compatible.
Re:Just rename it. (Score:4, Informative)
Re:Damn right (Score:5, Informative)
2. Python 3.0 includes a 2to3 script to convert existing Python code to Python 3
3. The incompatibilities are mostly mechanical, by far the largest is the change of "print" from a statement to a function (which simplifies the implementation and makes converting existing programs to log to files or whatever much easier). I've yet to find any of my code that 2to3 doesn't handle just fine.
Re:Another Shock Story (Score:2, Informative)
Re:Another Shock Story (Score:5, Informative)
for i in range(1000):
# do something
will remain unaffected, but code that does something like:
a=range(1000)
a[37] = 2000
for i in a:
# do something
will be affected.
The conversion tool and 2.6 interpreter will warn you about those things, and they're easy to fix ( "a=list(range(1000))" ) if 2to3 doesn't do them automatically. Which I'm not sure about, because they're highly unusual--2to3 has converted all of my personal code just fine.
It's not like this is the first time. (Score:3, Informative)
I didn't kill Python then, and it didn't stop us from using 1.5.2 for years to come for our old scripts and 2.x for our newer scripts.
Re:It's a race (Score:3, Informative)
According to this index, anyway, Python [tiobe.com] has a respectable base and is slightly ahead of Perl. But, yeah, they could pull it off at this point.
Re:I don't see the problem (Score:3, Informative)
Yes, there's the inevitable scary transition period with backwards incompatible upgrades, but after that's done, you'll be ready to reap the rewards.
I can't for example not thank Microsoft enough for making my life with Visual Basic code (yes, I have to deal with that occasionally in my job) far easier when they scrapped Visual Basic 6 and made something that must have been hundreds of incompatible changes to the language in Visual Basic 7 /
Granted, the difference will surely not be as great here, but this will most likely also mean that the transition will not be nearly as harsh either.
Re:Breaking backwards comp. in languages good (Score:2, Informative)
2. Once again, this is a problem with poor programmers, not the language. "And" and "Or" are the bitwise operators, equivalent to C#'s "&" and "|". "AndAlso" and "OrElse" are the logical operators, equivalent to "&&" and "||". I fail to see how the difference between "&" and "&&" is magically clearer than the difference between "And" and "AndAlso". If you can't remember the difference, than print up a cheat sheet.
By no means am I claiming VB.Net is perfect, because it definitely has some kludges, but at least pick legitimate ones.
Re:It does have block statements. (Score:3, Informative)
Wrong. Any decent editor can automatically indent code for you in any langauge where the proper indentation can be unambiguously defined by applying a series of rules to some other set of constructs in the language. This works for any language that has an unambiguous block structure even in the absence of any significance given to different whitespace patterns, which is true of lots and lots of languages, but, notably, not Python.
Because the interpretation of the block structure of Python relies on indentation, a Python editor can't automatically indent properly. Sure, as you are typing, it can give you a guess at where you might want to indent the next line that you only have to shift-tab or tab to get to where you do want it (and it can automatically handle tab->space conversion, etc.), but it can't automatically indent code that isn't already indented properly.
In a language with structure that is unambiguous before considering the detail of whitespace patterns (e.g., Lisp) and a decent editor, there is no "indent as usual". You just enter delimiters. When you feel like breaking a line, you do so. Your editor indents exactly right every time with no intervention. The only time you need to do anything manually to indent is after a cut and past operations, or after manually doing something that destroys the existing indentation for some reason, and all you need to do then is to tell your editor to automatically indent the line or region of code, and your are back to okay.
So, no, Python doesn't take away the need for delimiters and keep the same burden on indentation, it trades the burden of putting in and preserving the right delimiters for the burden of putting in and preserving the right indentation.
Copying and pasting code in a language that is structurally unambiguous before considering indentation, using a decent editor, requires telling the editor to automatically indent the block of pasted-in code. Usually that's selecting the code and and then hitting one keyboard shortcut. (Conceptually, an editor could be configured to automatically indent on an paste operation, but I don't immediately recall any that are by default.)
Copying and pasting code in a language where block structure is indicated by indentation alone usually requires selecting the code and then manually adding or deleting the right number of indentation steps to match the intended meaning of the code. This isn't a lot more burdensome, but it is clearly at least slightly more burdensome.
Not 100% (Score:2, Informative)
Re:It's not like this is the first time. (Score:5, Informative)
Many of them are backwards-incompatible changes that will remove nasty warts,
realign certain parts of python's object structure (str vs unicode, int vs long)
in ways that are MUCH cleaner, MUCH harder to make mistakes with, etc.
This is not some Larry Wall day dream revision...
they aren't rethinking python from the ground up,
it's an evolutionary revision which is keeping the python 2.x codebase,
but changing some things they've been wanting to do for a long long time.
The 1.x -> 2.x transition is apt... the code will look almost the same,
only cleaner
If that's not good enough for anyone, automated tools are being developed
to convert python 2.6 -> 3.0. Yes, that's right, Python 2.6. It'll
be the last version of 2.x released, and be carefully designed to be
both compatible w/ 2.x, and still able to warn you about gotcha's
that would appear if you ran the code under 3.0.
Not only that, but 3.0 isn't projected to be in mainstream use
for at least 2 more years.
There's absolutely no need for the sensationalist panic this slashdot headline
annouced itself with. Rethinking a complex system from the ground up is always
a bad idea... but GVR knows that, and that's not whats happening here.
It's more akin to the linux kernel moving from 2.4 -> 2.6
Incompatible, yes, but a much better architecture.
Re:It's a race (Score:5, Informative)
See, the funny thing is that the changes going into Python 3 are fixes for much of what people have complained about in Python 2.x and prior.
Moreover, every step of the way they've built translators to move code from 2.x compatibility to 3.0 compatible -- and it'll catch when it can't translate the code and tell you as much. It seems pretty slick from everything I've seen. In many cases the fixes are ones you could easily do yourself in seconds with a good text editor. This will be a minor speed-bump for most users
For more info, check out the recent Doctor Dobb's Journal interview (audio) with David Goodger [ddj.com] -- it's about PyCon 2008, but it also covers Python 3 as well.
Re:Python to not be backwards compatible (Score:4, Informative)
If it isn't backwards compatible, it isn't Python, as far as I'm concerned. I'm sure not going to be re-writing a couple hundred megabytes of code. They can take their incompatible new snakelike thing and smoke it. Foregoing backwards compatibility is about as dim a move as I've ever seen anyone outside of Microsoft pull (MS dropping VB underneath Access comes to mind as a comparable clueless act, with exactly the same consequences — it isn't the same product and is useless to me.)
The reason for breaking compatibility is to maintain the Python philosophy of not having a lot of ways to accomplish the same thing. Without periodic pruning, eventually you'd just have Perl with indents.
From what I've read, you'll be able to choose the version/style you want, and the 2.x and 3.x series will live alongside each other (I don't know whether the 3.x interpreter will have a compatibility mode, or if you'll have to keep the 2.x version around as a separate program, though).
Re:It's a race (Score:3, Informative)
Comment removed (Score:3, Informative)
Re:Breaking backwards comp. in languages good (Score:5, Informative)
This was actually introduced prior to
Personally, I like the way Turbo Pascal made you declare both upper and lower bounds. 0-based arrays make sense in a systems programming language when it's just a thin veneer for a pointer, but VB, C# and Java shouldn't force it on you.
In the original VB, "And" and "Or" operators did NOT do short circuit evaluation.
Beyond that, they were bitwise operators, not logical. The fact that 1 is true, 2 is true, but 1 AND 2 is false is far more perverse than the lack of short-circuiting. This is also why the canonical true value in VB is -1 (1111111111111111 binary) rather than the usual 1. This was appropriate in Bill G's 8K Altair BASIC, but it should have been fixed in MS BASIC well before 1980.
VB.Net Beta 1 made "And" and "Or" normal logical operators and introduced new bitwise operators for the old functionality, but too many people complained and they switched it back for Beta 2.
There are many other examples in VB like this
I don't know about that. Those are pretty much the worst parts that
Re:Breaking backwards comp. in languages good (Score:3, Informative)
Of course, C/C++ and its derivatives with short-circuiting by default have changed the landscape so much that today such behavior is expected by the majority of programmers, so perhaps the rationale is no longer as valid as its used to be (though one can argue that unexpected but consistent behavior is still better than expected but inconsistent).
Re:Breaking backwards comp. in languages good (Score:3, Informative)
You could do fancy things with NEXT in line number format, including violating the now common programming practices. After implementing blocked statements, you need to specify what you are ending in order to avoid a broken or mismatched FOR or IF block. As long as you remember that BASIC is a basic programming language for inexperienced people, you'll understand this.
Re:So, will it FINALLY have block structures? (Score:1, Informative)
Braces and brackets always work (except for a few long-obsolete systems confined to Scandinavia), but it's very common for whitespace characters to be munged by editors, mailers, and browsers. We see it all the time, even in this very forum. Why did you write "^T" in your comment? Because a real tab wouldn't have worked!
(Its codepoint is actually U+0009 or ^I, by the way, though the C escape is \t.)
Re:Python to not be backwards compatible (Score:3, Informative)
the problem is at some point they are going to drop support for it
Welcome to software development.
What products don't eventually become unsupported? Even a compiled language like C or C++ has libraries that eventually become unsupported, and maintaining them even if you had the source would become a difficult task.
Re:Damn right (Score:3, Informative)
4. Unicode will become the standard throughout Python. This is probably the biggest change. Whereas before the String datatype was synonymous with a byte array (and used for both), it no longer will be. This entails some additional changes in your code to specify the encoding of a String, which will now be represented as Unicode. A new datatype, called "Bytes" (IIRC) can replace the former byte array use of Strings.
5. Many modules in the Standard Library which have been marked deprecated for several versions now (and raised a DeprecationWarning exception) will now actually be removed. Several others with old naming conventions, ambiguous names, or dual Python/C implementations will be renamed, with an appropriate backward-compatible stub that issues the same DeprecationWarning exception, but still works with the old name. A running tally of modules to be removed/renamed is in PEP 3108 [python.org].
The bottom line is that they are not just making backward-incompatible changes for the sake of changing things. They are specifically trying to avoid "becoming the next Perl 6" to paraphrase Guido from one of his Google Tech Talks [google.com]. They are just taking this one chance to remove longstanding "warts" from the language in one fell swoop.
Almost everything will be covered by the 2to3 converter. Where required changes are ambiguous, 2to3 will issue a warning and request you fix it manually. I'd rather they fix the problems with the language now before they get any more entrenched. But then, I'm not a maintainer of "legacy" Python code. I am looking forward to the Generic Functions and Adaptation features (among other things) that are being discussed for Python 3000 though.
Re:Can we put in requests? (Score:2, Informative)