Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Software Upgrades

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."
This discussion has been archived. No new comments can be posted.

Python 3.0 To Be Backwards Incompatible

Comments Filter:
  • It's a race (Score:5, Insightful)

    by Intron ( 870560 ) on Friday February 01, 2008 @12:22PM (#22263270)
    Will the new Perl or the new Python be the first to shoot itself in the foot with incompatibility?
    • Python apparantly, Perl6 is backwards compatible with Perl5 even though it has many new features
      • by drolli ( 522659 )
        And i think perl 5 was compatible to perl 4 (AFAIR). Just adding things...
        I really dont want to know ho perl will look in 20 years....
      • Re: (Score:3, Informative)

        by Anonymous Coward
        Is Perl 6 backward-compatible with Perl 5?
        No. [programmersheaven.com]
        • Re:It's a race (Score:5, Informative)

          by IkeTo ( 27776 ) on Friday February 01, 2008 @01:16PM (#22264178)
          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: (Score:3, Insightful)

            Depending on who you talk to, this can be said to be backward compatible.


            At least the first form of "backward compatibility" mentioned (a translator for most older code) is also available (or a planned feature) for Python 3.0.
          • Yes, some kind of transition phase is the only approach that makes sense with established APIs. That's precisely why python is doing a 2.6 version to bridge the gap.
      • Re:It's a race (Score:5, Informative)

        by Incongruity ( 70416 ) on Friday February 01, 2008 @03:01PM (#22265750)

        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: (Score:3, Insightful)

      by hey! ( 33014 )
      Neither has to.

      The question is, who is going to have the hardest time interfacing to existing code?

      In either case, things are changing that could present challenges to this. Perl is going to a new virtual machine. Python is changing things like string handling. Either one could he a show stopper when it comes to using existing code.

      Neither Perl 5 nor Python 2 is going away. Interfacing with existing code would be a huge boost to either Perl 6 or Python 3, but of the two, I think Python 3 is more likely
    • by Crazy Taco ( 1083423 ) on Friday February 01, 2008 @01:28PM (#22264382)

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

      You know, sometimes a little backward incompatibility can be good. You can shoot yourself in the foot more by not breaking things when something needs fixing. As an example I point to VB.Net.

      Back in the days of VB 6 and prior, VB was an entry sort of language that was designed with novice programmers in mind, and strayed quite a bit from normal programming constructs. With the advent of the .Net platform looming, Microsoft wanted to move VB to .Net, but didn't want to break existing code out in businesses. So they opted instead for kludges and workarounds in the language, and that's the reason I can't wait to get done with VB .Net project I am currently writing. If you are an experienced programmer in other languages such as Java, C++, etc, VB .Net can drive you mad. Here are just a couple examples:

      1. Arrays. VB did not originally have 0 based arrays. Its arrays started at 1. In order to get VB to work with .Net, Microsoft really turned arrays into a kludge that is very difficult to remember (I almost always have to pull out an O'Reilly reference) and easy to get wrong. In a normal language, you declare an array of five integers and you get five slots numbered 0 through 4, right? Well not VB .NET! You declare an array of five integers, and you get SIX slots, numbered 0 through 5. And where most languages you would see "something - 1" when referencing array locations, in VB you often see "something - 2"! That really makes things annoying, especially if you've worked in .NET before with C#, because when you come over to VB you are almost guaranteed to biff things up.
      2. 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". Therefore, these new kludge operators certainly aren't the default operators most people think to use, so most end up using "And" and "Or" in the heat of coding, and VB code suffers and unecessary performance hit all over because short circuit evaluation isn't often used.

      There are many other examples in VB like this, so I say this to the Python developers: If you have a good reason to break backwards compatibility with the language, then do it. Keep backwards compatibility whenever reasonably possible, but break it before accepting a kludge into your language. Your future coders will thank you, and will not run away screaming to the other, newer languages that will inevitably follow.

      • Re: (Score:3, Insightful)

        "AndAlso" and "OrElse" are used by other languages such as SML, so it's not like some horrible thing that only Microsoft uses.
      • Re: (Score:3, Informative)

        Comment removed based on user account deletion
        • Re: (Score:3, Informative)

          by Sigma 7 ( 266129 )

          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

      • 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: (Score:3, Informative)

        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

    • 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: (Score:3, Interesting)

        by rk ( 6314 )
        You're not alone! I started with Python 8 years ago using 1.5.2 as well. I liked python then, but when python 2 came out, I went from liking python to it becoming a favorite language. I looked at one of my old python 1.5.2 scripts a couple weeks ago, and it looked very odd and a little clunky to me. If python 3 someday makes me look at my python 2 code in the same way, then as far as I'm concerned, it's all good.
        • by slackergod ( 37906 ) on Friday February 01, 2008 @02:52PM (#22265618) Homepage Journal
          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.

  • Just rename it. (Score:5, Interesting)

    by Besna ( 1175279 ) * on Friday February 01, 2008 @12:22PM (#22263278)
    Call it "Cobra" or something. Too many kludges will confuse people. A new name and file extension will emphasize that this is "in with the new".
    • by Neil Hodges ( 960909 ) on Friday February 01, 2008 @12:26PM (#22263342)

      There are already other [wikipedia.org] languages [wikipedia.org] doing this. If you think naming closely-related languages the same thing is a kludge, what do you think of naming mostly-unrelated languages the same thing?

    • Re:Just rename it. (Score:5, Informative)

      by Bogtha ( 906264 ) on Friday February 01, 2008 @12:39PM (#22263558)

      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.

    • I agree that if it is so incompatible it should have a name change. But I might suggest something a little less obvious like Python.three instead of using the three as a 3 versioning number.

      I hear the changes aren't supposed to be that drastic but then again, I have to wonder why the heads up if that was the case. Maybe as it gets closer, we will see that it is stuff so obscure that it won't bother 99% of everyone.
    • by Speare ( 84249 ) on Friday February 01, 2008 @12:54PM (#22263818) Homepage Journal

      Python's named after the troupe Monty Python, not after the snake species. I don't think renaming it is a good idea, but suitable successors would be [Life of] Brian, [Fish Called] Wanda, Flying Circus, Holy Grail or perhaps start with sub-versions like Cleese, Chapman and Palin.

      Alternatively, pick another troupe or favorite comedy show: Fry and Laurie, Mr. Bean, Fawlty Towers or Red Dwarf. Or my favorite, which brings back in the snake species AND British comedy into circular pun, Blackadder.

      While talking about puns, snakes and coming full circle, I suggest Ouroboros.

      • Re: (Score:3, Funny)

        by Ilan Volow ( 539597 )
        Supervisor: 'Did you finish debugging your python scripts that update the database?'.

        Me: 'Yeah. They're ready to go, and they're all Fawlty now'.

        I think we better stick with "Python". Or "Smeghead".

      • A cunning plan (Score:3, Insightful)

        by Anonymous Coward
        Calling the new language "Blackadder" is a plan so cunning that if you put a tail on it you could call it a weasel.
    • Re: (Score:3, Interesting)

      by Kludge ( 13653 )

      Too many kludges will confuse people.
      Yeah! Get lost all you wanna be's!

      Seriously, what really matters is:
      #!/usr/bin/python2
      or
      #!/usr/bin/python3

      And I'm betting someone will come up with
      #!/usr/bin/python
      that will automatically determine which python it is from the syntax.
  • Another Shock Story (Score:5, Informative)

    by LowSNR ( 1138511 ) * on Friday February 01, 2008 @12:23PM (#22263292) Homepage
    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.
    • by betterunixthanunix ( 980855 ) on Friday February 01, 2008 @12:35PM (#22263504)
      No, but that means that everyone planning to run non-Python3 code will have to maintain two parallel Python installations. With package management that's not so bad, but it still puts a bit of pain on distro maintainers.

      Yet everyone makes fun of me when I say that I am a C++ programmer.

      • No, but that means that everyone planning to run non-Python3 code will have to maintain two parallel Python installations. With package management that's not so bad, but it still puts a bit of pain on distro maintainers.

        This is already done in the distros I've seen.

    • by onion2k ( 203094 ) on Friday February 01, 2008 @12:38PM (#22263548) Homepage
      It is an issue though. PHP did exactly the same between version 4 and 5, and it crippled adoption of 5 because hosts refused to upgrade as it'd have broken too much code. It was a full 3 years or so before 5 was really considered the primary version amongst many developers and that took the announcement of 4.x support ending and the success of the GoPHP5 campaign.

      Hopefully the Python team will learn from PHP's experience.
      • Re: (Score:3, Insightful)

        by misleb ( 129952 )

        It is an issue though. PHP did exactly the same between version 4 and 5, and it crippled adoption of 5 because hosts refused to upgrade as it'd have broken too much code

        Not a big issue for Python, methinks. Python is not generally used in hosted environments like PHP is. At least not in the same proportion. PHP's only real strength is its install base. You can get it on just about any host. To make a comparison outside of languages, PHP is like WIndows. The major selling point is its ubiquity. In which ca

      • by alexhmit01 ( 104757 ) on Friday February 01, 2008 @02:16PM (#22265162)
        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.
        • Re: (Score:3, Funny)

          by raehl ( 609729 )
          PHP 5 was a MAJOR over-haul, biggest since PHP 4.

          One can only guess when the next major overhaul will be. Who knows, it might even be PHP 6.
    • Especially since, y'know, the plan to let Python 3000 be backwards-incompatible has been in place for at least two years now.

      *shrug*
      • Re: (Score:3, Informative)

        by Bogtha ( 906264 )

        It's been a lot longer than two years. For example, see this thread [google.com] 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).

  • by fahrbot-bot ( 874524 ) on Friday February 01, 2008 @12:26PM (#22263328)
    I think I have a Perl script that'll fix this...

    Just kidding Python fanbois :-)
    Chill, it's Friday.

    • Re:Workaround... (Score:5, Informative)

      by tuffy ( 10202 ) on Friday February 01, 2008 @12:30PM (#22263438) Homepage Journal
      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.
      • Actually, the article says that 2.6 and 3.0 will be released around the same time:

        The Python development community was committed to providing a smooth upgrade path and will build a number of forwards-compatible new features into the next release of the current version of the language, version 2.6. This release is expected to come out around the same time as the release of 3.0, said Baxter.
  • by spookymonster ( 238226 ) on Friday February 01, 2008 @12:27PM (#22263376)
    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.
    • by Bogtha ( 906264 ) on Friday February 01, 2008 @12:43PM (#22263636)

      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: (Score:3, Interesting)

      by Wiseman1024 ( 993899 )
      A good one though. Statements are stupid. Probably Python's biggest flaw. It's good that they're getting rid of a couple of them, though while, if and the like still remain.

      If you're wondering why statements are stupid: they are not first class values you can pass, use and manipulate; they introduce a special, harder to learn and very quirky syntax; they cannot be used anywhere and thus subtract flexibility; and they are an extra form or feature that's actually unnecessary ("Programming languages should be
  • by Urger ( 817972 ) on Friday February 01, 2008 @12:28PM (#22263380) Homepage
    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.
    • Re: (Score:3, Informative)

      by Jugalator ( 259273 )
      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 cha
  • We have options. (Score:5, Insightful)

    by Sludge ( 1234 ) <[slashdot] [at] [tossed.org]> on Friday February 01, 2008 @12:28PM (#22263388) Homepage
    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.
  • Whiners (Score:5, Insightful)

    by MikeDataLink ( 536925 ) on Friday February 01, 2008 @12:29PM (#22263408) Homepage Journal
    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. ;-)
  • meh (Score:5, Insightful)

    by seanyboy ( 587819 ) on Friday February 01, 2008 @12:29PM (#22263412)
    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.
  • Sounds like they are definitely going for a version 3 of the language. They have identified what they need to fix and add to version 2 and are going to implement it in version 3. I have messed with python so I don't have a heavy code investment in it yet but either way - if it makes Python better than it is, I think its worth considering.
  • ... as I can have them installed side-by-side. Perhaps make the executable python3 or something to use different shebang lines (#!/usr/bin/python and #!/usr/bin/python3). If I recall correctly most OS's use a symlink python to the version anyway.

    Would make the transition easier for everybody. My OS of choice (Gentoo) uses Python as the distribution method.
  • I applaud these guys for having the balls to say "I'm going to take what I've learned from the mistakes I made in versions 1 and 2, and start over with something better". I love Java, but I sure wish some of the 1.1 and 1.2 cruft would go away.
  • by Arthur B. ( 806360 ) on Friday February 01, 2008 @12:31PM (#22263442)
    Look at C++, they broke backwards compatibility with C ( malloc casting for example ) and because of that it never became mainstream.
  • Almost 2 years old? (Score:5, Informative)

    by Anonymous Coward on Friday February 01, 2008 @12:31PM (#22263446)
    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. :)
  • by spookymonster ( 238226 ) on Friday February 01, 2008 @12:31PM (#22263456)
    The "What's New for 3.0?" article over on python.org:

    http://docs.python.org/dev/3.0/whatsnew/3.0.html [python.org]
  • Last year, both Ubuntu upgrades (from 0610 to 0704 and then to 0710) each sent me into Python version mishmash/compatibility hell. But at least they could be mixed together a little, to bootstrap back to a working installation.

    I wish these scripting languages were really just APIs, and could all be compiled to binary code instead of depending on different versions of different interpreters. The script source is just too transient without needing to be when working under the hood.
    • by nuzak ( 959558 )
      > I wish these scripting languages were really just APIs, and could all be compiled to binary code instead of depending on different versions of different interpreters.

      So basically, you're looking for .NET or Java or Parrot then. All three of 'em do run Python. Of course each of those is itself an interpreter...

      Python3000 had some pretty grand visions. Optional static typing. Generic functions. Look what we got: meaningless type annotations on functions, not even on locals. "Abstract Base Classes"
      • How do I eliminate all the Python VMs and libraries from my system to instead run the Python scripts against only my single Perl installation? Even if I have to install a bunch of Perl modules to do it.

        But to really do waht I want, I'd need to actually compile those Python scripts in with the Perl executables, which I thought was too hard with autoloading and other dynamic runtime execution.

        The Perl scripts can stay interpreted. They've never caused me any version trouble yet. Though I wish every CPAN downl
  • 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.

    I'd like to hear from slashdotters who used to blame Microsoft when Microsoft release software that broke backwards compatibility with existing versions. Is Python's development team following Microsoft's lead here?

  • Not news in any way (Score:5, Informative)

    by Bogtha ( 906264 ) on Friday February 01, 2008 @12:36PM (#22263510)

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

  • philosophy (Score:3, Insightful)

    by bcrowell ( 177657 ) on Friday February 01, 2008 @12:36PM (#22263512) Homepage

    IIRC, even dot-releases of python are not source-compatible. I assume that's why my install of Ubuntu has multiple versions of every library, e.g., /usr/lib/python2.4/smtplib.py and /usr/lib/python2.5/smtplib.py.

    I think this is partly a matter of philosophy. The people in charge of a particular language tend to be computer language enthusiasts, and they like to tinker with them. They say things like, "The language has to be able to continue to evolve, or else it will die," or "We don't want to lock in things that, in retrospect, were really mistakes." But people actually using the language typically put a higher priority on not having their code break. Obviously we wouldn't all want to still be writing old-style fortran, with fixed columns, Hollerith codes, etc., but I also don't agree with the philosophy that "bit rot" is inevitable, and every piece of code you write is like a baby that you have to tend for the rest of your life. Personally, one of the things I really like about Perl is that it's got an excellent, mature implementation, and it's been mature for a long time. This is a lot less true for Ruby, for example, in my experience. It's true that Perl 6 is going to break backward compatibility with Perl 5, but the Perl 6 interpreter is going to automatically recognize Perl 5 code, and handle it correctly.

  • by pembo13 ( 770295 ) on Friday February 01, 2008 @12:36PM (#22263522) Homepage
    && you use python, please turn in your developer card
  • While I'm not much of a Python programmer, it is refreshing to see projects are are not afraid to risk breaking compatibility in the name of progress and getting rid of legacy cruft. One thing I noticed about Python the few times I tried it was that there seemed to be a lot of ways (many of them officially "obsolete") of doing the same thing. One bit of confusion I recall is trying to call the "super" method of a parent class when you've overridden a method. In my research I found several long articles abou
  • Python 3000 (the draft for Python 3) has been in the works since 2006 and it has quickly been made quite clear that backward compatibility would be broken.

    Well I guess old news is better than no news at all...
  • by Animats ( 122034 ) on Friday February 01, 2008 @01:09PM (#22264072) Homepage

    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.
  • Shocking! (Score:3, Funny)

    by smallpaul ( 65919 ) <(paul) (at) (prescod.net)> on Friday February 01, 2008 @01:17PM (#22264196)
    Guido is following through on the plans he announced years ago! Let's all discuss it as if it were amazingly novel news!
  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Friday February 01, 2008 @03:24PM (#22266096)
    Comment removed based on user account deletion

"Oh what wouldn't I give to be spat at in the face..." -- a prisoner in "Life of Brian"

Working...