Slashdot Mirror


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

12 of 438 comments (clear)

  1. It's a race by Intron · · Score: 5, Insightful

    Will the new Perl or the new Python be the first to shoot itself in the foot with incompatibility?

    --
    Intron: the portion of DNA which expresses nothing useful.
  2. I don't see the problem by Urger · · Score: 5, Insightful

    While it would be nice if it were otherwise, sometimes you need to break with the past to develop solutions to problems. It's an ugly, but very real truth. Thats not to say that my I will be rewriting my code to 3.0 immediately, but sometime in the next year or two I probably will.

  3. We have options. by Sludge · · Score: 4, Insightful

    I maintain tens of thousands of lines of Python... and I'm not worried. Why? Because I am sure they will continue to support security and bugs on the 2.x line for a long time to come.

    It is not like your favourite Linux distro is just going to drop the 2.x series overnight, or like Python 3 will fight 2.x on your system.

  4. Whiners by MikeDataLink · · Score: 5, Insightful

    We whine when companies break compatability, yet we whine just as loud about bloated software when companies leave in compatibility.

    Tell, me exactly what would satisfy you? How about we just take your computer away.

    I'm running for president! FREE PACIFIERS to all Slashdotters. ;-)

    --
    Mike @ The Geek Pub. Let's Make Stuff!
  5. meh by seanyboy · · Score: 4, Insightful

    As long as you can run Python 2 & 3 in the same environment, this shouldn't be a big deal.
    It'll just be a case of slowly moving code from one version to the next.

    This is a brave move, but you've only got to see the mess you can get into trying to force backward compatibility for too long (Vista, anyone) to know it's the right move.

    Of course, this being python, I fully expect some brainbox to come up with an automated conversion routine (v2 to v3) that "WAS WRITTEN IN ONLY 15 LINES OF CODE". etc, etc.

    --
    Training monkeys for world domination since 1439
  6. If this is news to you by pembo13 · · Score: 4, Insightful

    && you use python, please turn in your developer card

    --
    "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
  7. The Microsoft route by mariox19 · · Score: 4, Insightful

    Exactly! Now they can force people to buy expensive IDE's and servers to run the new version of Python, and strong-arm people into purchasing licenses to use the language for commercial purposes. It's just a money making ploy.

    Oh, wait a minute. All the old versions are going to continue to be available -- even the source code. And it will remain free for commercial use. Hmmmm.

    Sorry, but I fail to see how what they are doing is at all like Microsoft.

    --

    quiquid id est, timeo puellas et oscula dantes.

  8. Re:So, will it FINALLY have block structures? by msuarezalvarez · · Score: 4, Insightful

    Indentation is a derived piece of structure, but should never have semantic meaning in a language except as a separator.

    Why, exactly, is it that it should never have semantic meaning? Is there a rule somewhere?

  9. How did that Cripple PHP by alexhmit01 · · Score: 4, Insightful

    PHP 5 was a MAJOR over-haul, biggest since PHP 4. When PHP 4 came out, hosts and OSes supported 3/4. PHP 3 has really cool, but extremely insecure, syntax things for web prototyping. When you posted a variable, put it on the query string, or passed it in a cookie, it just came into the script as ${name}. So if you needed to check for setting, it was isset($variable), using it was just using it, etc. This was dangerous because in PHP you don't declare your variables, so if you assumed that a variable you never zero'd/nulled before usage was null at the beginning, this could be exploiting by posting a value.

    PHP 4 had a php.ini setting to use the old mode (I think register globals or something similar) that helped in the migration. Also, include_once/require_once massive simplified using libraries. Before that we had to do our own equivalent of ifdef/ifndef in our PHP code to avoid overwriting a function if two included libraries called it.

    The PHP 3 -> PHP 4 transition took a while as well. What's the rush, my new systems all include PHP4 AND PHP5. All my new code is PHP 5. My PHP4 stuff happens to be in legacy mode, but if I needed to bring it will us, you put it on a machine and see what works, what doesn't, and add support for 4 AND 5, like we all used to do on PHP 3/4.

    Better to introduce some source incompatibility for improvements then not being able to move forward, just make sure that there is a transition strategy. Three years isn't really that long... though when I started in web stuff, 3 years was an eternity, but 8 years later, eh, just a few more years.

  10. A cunning plan by Anonymous Coward · · Score: 3, Insightful

    Calling the new language "Blackadder" is a plan so cunning that if you put a tail on it you could call it a weasel.

  11. Can we put in requests? by the-matt-mobile · · Score: 3, Insightful

    If we're breaking compatibility, can we put in requests? The 3 main things I'd like to see are:

    1.) Ditch the silly ":" at the end of the line when starting a block. Why on earth is this needed? I almost always forget to use that darn colon.

    2.) Ditch the bolted OO on "self" variable for object methods. Just make "self" a keyword and use it the way "this" works in Java/C#/C++.

    3.) Allow for a whitespace agnostic mode with the end keyword the way Boo did for goodness sake! Why on earth is that so hard? If you want significant whitespace, it can still be the default. If significant whitespace drives you mad, then use a -wsa switch and a new "end" keyword and be done with it. It would end the flamewars and make Python a more acceptable language to those of us who prefer to have the option of aligning our code the way that makes the most sense, not the way the language Guido thought it should always be.

  12. Re:Python to not be backwards compatible by timmarhy · · Score: 3, Insightful

    the problem is at some point they are going to drop support for it, and no modules will begetting written for it either. the fact that you can maintain it yourself is a retarded response to this, because people who say it have pretty much no idea how much extra work that puts back on you, and frankly no one wants that.

    --
    If you mod me down, I will become more powerful than you can imagine....