Python 3.0 To Be Backwards Incompatible

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

Comments

Another Shock Story

[LowSNR]

If the editors read the article rather than posting shock stories, Python 2.6 will also be released at the same time and will not break backwards compatibility. Python is not pulling the rug out from under its developers as the summary would lead you to believe.

Re:Another Shock Story

[Anonymous Coward]

This is just not true. There will be a utility included with py3k that converts most purely syntactical differences from py2.x code into compatible running py 3.0 code. The official word on this is that the recommended upgrade path is to maintain your codebase as 2.x code that can also be converted into python 3.0 code in a completely automated way (that is, keep it compliant with py 2.6, but change things so that the automater script can generate py 3.0 code). When backwards compatability is no longer needed you can convert to the 3.0 codebase.

If anything its a long term upgrade path, not some "OMG EVERYTHING WILL BREAK NEXT YEAR" type crisis.

Re:Another Shock Story

[Bogtha]

It's been a lot longer than two years. For example, see this thread from eight years ago:

The new release schedule provides for a 1.7 release later in 2000 (or early 2001); after that, we'll be working on "Python 3000" (the new code name for the grand Python redesign; the language will be incompatible).

And from a reply:

(personally, I'd be very surprised if the changes were such that old code couldn't be automatically translated).

Re:Another Shock Story

[Eli_Courtwright]

The Python dev team knows that it will take years for Python 3.0 to be considered the default for most people; they've said as much on their mailing list. That's one of the main reasons why they're backporting as many features as they can to the 2.6 release - basically everything that doesn't break backwards compatibility.

Re:Another Shock Story

[pthisis]

Python2.5 and later let you write 3.0-compatible code. Just put parens around your print statements and you're probably fine to run in 2.5, 2.6, or 3.0. There are a few other changes which 2to3 and the 2.6 interpreter will warn about, but they're relatively rare. e.g. range will return an iterator instead of a list; code like:

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.

print as function vs. keyword

[spookymonster]

The biggest incompatibility is how you output to stdout. Instead of doing

    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:print as function vs. keyword

[Bogtha]

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

[tuffy]

Actually, Python2.6 is slated to include a tool which will update purely syntactic differences to Python 3 automatically. There are some issues it won't be able to fix, but Python2.6 will have a mode which will generate warnings about those so that they can be fixed well before Python 3's release.

Almost 2 years old?

[Anonymous Coward]

People only reading the summary and shooting from the hip should realize:

• 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

[spookymonster]

The "What's New for 3.0?" article over on python.org:

http://docs.python.org/dev/3.0/whatsnew/3.0.html

Not news in any way

[Bogtha]

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, 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.

in fact, such a utility already exists

[Reality Master 201]

http://svn.python.org/view/sandbox/trunk/2to3/

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.

[Bogtha]

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:Damn right

[maxume]

So put #!/usr/bin/python2.6 or whatever in your scripts and don't worry about it for 5 years(probably much longer, due to the significant changes, 2.6 will probably last nearly forever, or at least until basically nobody is using it anywhere).

Or does Ubuntu launch things based on file extensions?

Re:It's a race

[Anonymous Coward]

Is Perl 6 backward-compatible with Perl 5?
No.

Re:#1 way to prevent adoption of new language vers

[Llywelyn]

Relax.

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.

Python takes a step backwards.

[Animats]

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.

[BrunoUsesBBEdit]

Yikes don't do that because the choice of the name Python has nothing to do with Serpentes. It was chosen because of Monty Python's Flying Circus. So, the associations would be more like: Chapman, Idle, Gilliam, Jones, Cleese, Palin. Or it could be other comedy teams like: Mad, Saturday, Color, Hall, State, etc.

Further more, if you don't already know that, why are you posting?

Re:It's a race

[IkeTo]

From Perl 6 FAQ (http://dev.perl.org/perl6/faq.html)

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

[orclevegam]

Because whether or not it's a lie is largely a technical question that's somewhat open to interpretation. If by backwards compatible you mean is the old Perl5 syntax valid Perl6 syntax, then the answer is no. If however you mean will my old Perl5 scripts run in the Perl6 interpreter, then the answer is yes. Further more the old Perl5 modules (as per your link) will still be usable from Perl6, and there will be a converter to update the Perl5 scripts to Perl6 syntax. So, a better answer to the question of "Is Perl6 backwards compatible with Perl5?" might be "maybe".

Re:Damn right

[pthisis]

1. Python 2.6 is still due out and will be supported for years.
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.

It's not like this is the first time.

[Valdrax]

I mean, am I the only one who's been using Python since at least 1.5.2? The made major changes between that version and 2.0 that broke almost all of our 1.5.2 scripts (particularly in the way they handled regular expressions).

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 not like this is the first time.

[slackergod]

Indeed. You should read up on the changes they're planning to make.
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

[yo_tuco]

"I think Python has a small enough user base that they could actually pull it off."

According to this index, anyway, Python 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

[Jugalator]

I agree. If you keep not trying to break things, the end result can easily be worse than if you dare to do.

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 / .NET and onwards. The reward was a full fledged object oriented language that can barely even be compared with its hack job to a predecessor.

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

[thejeffer]

1. When you declare the array, you pass the upper bound of the array, not the length. Take two seconds to read the language syntax, and it clearly states this. These are zero-based arrays, so the upper bound of an array of 5 elements would be 4. No, it's not the same as Java or C++, but that's because it's NOT Java or C++ style syntax. If you want that, use C#. As far as your claim of "something - 2" being all over the place, I've never once used anything like that, and I've also never seen it in use. There'd be no reason for it. Arrays are zero-based, just like most other common languages, so just like them, you'll still use "something - 1". Don't blame poor code on the language. Blame it on the poor programmer.

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.

[DragonWriter]

Any decent editor can automatically indent code for you in any language,

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.

and in this case Python is even easier because all it uses is the indentation, so you don't have to manually add additional delimiters in the appropriate places;
just indent as usual.

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 any language requires you to reindent it just as much as with Python, lest it become an unreadable mess,

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%

[agbinfo]

I had to port Perl 4 code to Perl 5 and there were some issues.

Re:It's a race

[Incongruity]

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 -- it's about PyCon 2008, but it also covers Python 3 as well.

Re:Python to not be backwards compatible

[Kadin2048]

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.)

I don't think anyone is really suggesting that a lot of code be rewritten. Python 2.x isn't going anywhere, for exactly the reasons you bring up. Python 3.0 is going to be almost a completely new product, and I expect it'll only be used for new projects. I'm not really sure why anyone would want to convert their old code, if it works for you the way it is.

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

[cheater512]

Perl and Python are both open source so no marketing executives are involved. :)

Re:Breaking backwards comp. in languages good

[the-matt-mobile]

Preach it Crazy Taco! My biggest annoyances with VB.NET are the things they kept around just to make the VB6 devs feel more comfortable. Such as:

1.) "Dim"? Why the heck did they keep the "Dim" keyword!?

2.) When you see "SomeRandomlyNamedThing(7)", is that a method call or an array index? Why on earth did Microsoft keep parens as the array indexer?

3.) Option Strict is off by default.

4.) "&" for string concatenation!? I guess when you leave Option Strict Off, it's required, but blech!

5.) You can't stop people from using Left(), Right(), Mid() and other legacy functions because you have to include the Microsoft.VisualBasic in order to get vbCrLf and vbTab. Otherwise your code would be filled with Char(10), Char(13), and Char(9) all over the place.

6.) It's still a second class language to C#. No Yield keyword and no ++ and -- operators.

7.) Modules. Blech. Just let people get used to the idea of static classes instead of trying to make an OO language look like a functional one.

8.) Microsoft thinks VB devs are way too dumb to get namespaces so they try to hide them. Why on earth don't namespaces follow the directory structure of the source files by default? This is a killer when using embedded resources (which is a handy alternative to hard-coded SQL strings).

9.) Why oh why do I have to have 'Sub's. Why can't a 'Sub' just be a 'Function' with a void return type?

10.) Why do I have to tell VB what I'm "End"ing? "End For", "End Function", "End If" - wouldn't "End" be sufficient and then you could put a comment if you really cared what you were ending?

I could go on and on. The worst part is - since VB.NET broke compatibility with VB6, why didn't Microsoft just go the rest of the way and make the language better? They stopped short. This, I hope, is not the fate of Python. There are many ways to make the language better (white space agnostic option perhaps?), so I hope they don't waste their decision to break compatibility by leaving purposeless annoyances like Microsoft did with VB.

Re:Breaking backwards comp. in languages good

[Doctor Faustus]

Its arrays started at 1. In order to get VB to work with .Net
This was actually introduced prior to .Net. I'm not sure when, exactly, but VB6 is the same way. Actually, VB6 is pretty schizophrenic about 0 vs. 1 based indexes in general. I used to make a habit of just putting in a breakpoint and looking at the array while the program ran, instead of trying to remember which was which.

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 .Net didn't fix. There are some clunky IO libraries clearly designed to be used by the migration wizard, but they're strictly optional. Plus, I really like that VB.Net still has real optional arguments, as opposed to C# that goes the Java route and makes you declare a little stub version with fewer arguments that just calls the real one and fills in a default value.

Re:Breaking backwards comp. in languages good

[shutdown -p now]

Arrays. VB did not originally have 0 based arrays. Its arrays started at 1.

This is false. Arrays in all versions of VB were 0-based by default, as they were in all prior Microsoft dialects of BASIC, and as they were in the original BASIC interpreter. It always worked that way in BASIC: "DIM a%(10)" got you an array of 11 integers, with indices from 0 to 10. A QBasic extension to that which made its way into VB was the ability to define the lower bound explicitly, similar to Pascal. So you could write "DIM a%(1 TO 10)" in VB, and indeed most people did that for the sake of convenience. Alternatively, one could use "Option Base 1" to change the default lower bound in the scope of a single module. VB.Net only got rid of that ability to expicitly define the lower bound for the sake of efficiency and CLS compliance (non-0-based arrays are possible in .NET, just much less efficient than 0-based).

Logical operators. In the original VB, "And" and "Or" operators did NOT do short circuit evaluation. To avoid breaking code, Microsoft introduced even more operators, "AndAlso" and "OrElse". Those two operators are just like "And" and "Or" except that they do do short circuit evaluation, but good luck trying to remember to use them when coding quickly. I know when I code and want to "And" things together, I think "X And Y", not "X AndAlso Y".

The default form of boolean operators is a matter of preference. FYI, the OrElse/AndAlso operators come from Ada (only there the latter is "and then"). The rationale is that, in an imperative language, short-circuiting behavior is surprising since it results in a silent omission of side effects of an expression. What's worse, it happens under some runtime conditions but not under others. If a developer misses it, he can get the code that works 99% of the time (when only the left operand is evaluated), and fails 1% of the time (when right operand has to be evaluated, and its side effects cause a bug). Therefore, making it a default is dangerous. On the other hand, non-short-circuiting operators, while potentially less efficient, at least display consistent behavior. Also, if expressions on both sides are trivial enough (e.g. inlined function calls), the compiler can verify the lack of side-effects, and short-circuit the operator where it is safe. In the worst case, you pay for less obscure bugs with a relatively small perfomance penalty.

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

[Sigma 7]

10.) Why do I have to tell VB what I'm "End"ing? "End For", "End Function", "End If" - wouldn't "End" be sufficient and then you could put a comment if you really cared what you were ending? "End" is a keyword for termininating the application, and was like that since basic was invented. END IF and the likes were added when Basic was modified to use free-form code rather than sticking by line numbers that were in increments of 10.

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?

[Anonymous Coward]

The difference between a { character and a ^t character is... well, there is no difference except their ASCII code.

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

[Vellmont]

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

[ben there...]

To expand on that:

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.

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. 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?

[debatem1]

I'm posting this all over this thread. If you like curly braces, this might be what you're looking for. It's called curlyPy, and it allows you to just use k&r or java style curly braces to delimit blocks, and to hell with whitespace.