SIDEBAR
»
S
I
D
E
B
A
R
«
Python 3.0: What’s The Point?
December 4th, 2008 by jens

Python 3.0 is finally out. I like Python (though it and Ruby are always competing for my affections), and I’m always a sucker for new features in any language, but I’m having trouble getting excited about this. Despite the longtime code-name “Python 3000”, it doesn’t seem very futuristic; and it introduces a lot of compatibility problems. In fact, after reading the docs, I can’t come up with any good reasons to install or use the new version. Am I missing something?

Looking at the official What’s New page, my takeaway is that the benefits are:

  • A bunch of minor language features cleaned up
  • Better (at least less confusing) Unicode support
  • Some nice but minor new syntactic features

while the drawbacks are:

  • Won’t run any pre-existing Python software. Just one minor example: the xrange() function no longer exists; instead, range() behaves the way xrange did. I’m pretty sure I’ve written something like “for i in xrange(a,b)” in every significant Python program I’ve ever written, causing all of them to break in 3.0 until I update them. Which is trivial; but there are dozens and dozens of changes like this. And many of them won’t cause easy-to-diagnose exceptions like the removal of xrange; some just cause subtle changes in behavior that will likely require debugging if they’re overlooked. (There is apparently an automated code converter, but of course it won’t fix everything.)
  • As a side-effect of the above: All existing Python books are now out-of-date. (Sure, much of each book’s coverage is still accurate, but the reader who’s not a Python 3 expert already won’t know which parts are OK and which are now wrong.)
  • Programs written for Python 3.0 probably won’t run in any earlier version of the interpreter, since most of the changes aren’t backward-compatible.
  • Slower performance: “Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5.”

Something seems wrong here! the benefits are minor, the drawbacks are huge. Where’s the incentive to use it?

Compare this to the Ruby 1.9 story: A number of language improvements; they’re mostly backward-compatible, although with enough exceptions to break lots of large apps like Rails). But oh yeah: it’s three times as fast. That’s a very big deal, considering the poor performance of today’s Ruby (and Python). Once the 1.9 tech appears in a stable release, I am definitely upgrading.

Or compare to an operating system upgrade. How would you respond to a pitch like: “The ‘Meerkat’ release is going to be incredible! We’ve made a number of improvements to the system libraries. Of course, all existing apps will break, so you’ll have to get upgrades from the developers (which won’t run on earlier OS’s, by the way.) And afterwards you’ll notice everything running 10% slower! But we’re sure you’re going to love the enhancements to iterators and Unicode support…”

So what did I miss? I don’t mean this as an attack; I’m just genuinely confused…

Update: See also my further thoughts in response to James Bennett’s article.


90 Responses  
  • Steve Johnson writes:
    December 5th, 20081:32 PMat

    I don’t know about that; the What’s New document prominently states “Everything you thought you knew about binary data and Unicode has changed” and then later says “pretty much all code that uses Unicode, encodings or binary data most likely has to change”. This does not give me warm fuzzies, considering how tricky and subtle text-encoding issues can be.

    Unicode/encodings/binaray data code must change so that it is no longer “tricky and subtle.” This is why people are so excited about proper Unicode support.

  • Jason writes:
    December 5th, 20081:38 PMat

    All these people who have no time to deal with porting their codebases to 3.0 within the next some odd years that the 2.x line will be supported, who have been sitting idly by without a plan while this backwards-incompatible break point has been discussed for years now - they’re going to instead change language platforms altogether? If you’re so upset about this, what do you think the Python folks should have done differently? I don’t think it’s possible to be any more transparent, open, and deliberate about the transition process… so, seriously, what do you want?

  • Jens Alfke writes:
    December 5th, 20081:39 PMat

    Steve— No, you missed my point. Text encoding issues can be intrinsically tricky, regardless of the API or language. I’ve run into my share in Cocoa, which has good Unicode support. I’m sure Python 3 will make it easier to write correct text-handing code; but the prospect of messing with existing text code to port it over is kind of scary, considering how easy it can be to break things in the process.

  • Eric writes:
    December 5th, 20081:47 PMat

    Jason,

    Not everyone has time to “follow” a language as you do. Most are just trying to get work done. This break is bad, not because changing any one piece of code will be hard, but the sheer size of the library and support base that needs to change. If you are writing any non-trivial code in python you are now at the whims of your libraries as to when you need to upgrade.

  • Jens Alfke writes:
    December 5th, 20081:50 PMat

    Jason— I think the Python folks should have preserved backward compatibility, either by not introducing incompatible changes, or by providing an automated shim that allows old-style code to run (not a converter that only does “most of” the work.)
    Or alternatively, they could have taken the opportunity to make larger changes in the language. Just off the tip of my tongue: data encapsulation (private members/methods), better syntax for operator overloading, true blocks, optional data typing as was proposed for JavaScript 2. Now that the barn door on incompatibilities has closed again, changes like these that break compatibility probably won’t be discussed until Python 6…

    Yes, I wasn’t paying attention to the details of the Python 3 design process. I’m just not that deeply involved in Python. So my perspective is that of an interested bystander who has used Python and has a reasonable command of the language, but doesn’t use it 40 hours a week. And from that perspective, when I see a “New! Python 3.0! Shiny!” announcement, and then read through the what’s-new document, there’s a certain amount of “WTF?”

  • Nick writes:
    December 5th, 20081:52 PMat

    I don’t know about that; the What’s New document prominently states “Everything you thought you knew about binary data and Unicode has changed”

    Yes, this is a big change, but the fact is that it’s exactly the change you want. Having both str and unicode types in Python opens you up to lots of subtle bugs that you’d rather banish from your code. If you’re using unicode everywhere in your code now, then the change is very transparent. If you’re using some mixture of str and unicode, then the change is more difficult, but it’s the difficulty of moving everything to unicode (which is what you want to do) not the difficulty of moving to python 3, if that makes sense.

    It’s a shame python wasn’t unicode from the start—-but it was 1991 and it is understandable that it wasn’t a priority for a new language. Due to its success, though, it was never able to shed this fundamental wart and here it is 2008. As a said before, Python 3.0 in 2008 means that in 2011 must of us can be using a Python that is pure Unicode. The alternative is for it to be 2011 and python programmers still pining for Perl 6 I mean, Python 3000.

  • Raymond writes:
    December 5th, 20081:52 PMat

    Several Python books are being updated for 3.0 and will be out before long.

  • Jason writes:
    December 5th, 20082:15 PMat

    @Eric - I don’t spend a lot of time “following” Python. You act as though the impending change was a secret buried deep in the bowels of the developer mailing list, but that’s just not the case. If you use Python, and you really didn’t know that Py3k was coming, and that it was going to break backwards compatibility, then I think you were shirking your professional responsibility to stay informed about the state of your tools. As for being at the whim of your libraries in terms of upgrade schedules: that’s always the case, to some degree (yes, backwards-incompatible does make it harder). But Python’s batteries-included philosophy does mitigate this quite a bit.

    @Jens: I don’t understand what you’re saying, none of those “larger changes” that you just listed would necessarily break backwards compatibility. What’s wrong with waiting until 3.1 if they’re needed?

  • John writes:
    December 5th, 20082:27 PMat

    Your pros/cons are true, yet they simply highlight the only reason to upgrade to Python 3 is because you want to program in Python 3. That’s it.

    It’s kind of like the only reason to program in Python 2 is because you wanted to program in Python 2. Compare Python to an older but similar language like Common Lisp, and you’ll find it has essentially the same benefits (very similar features, slightly nicer syntax) and drawbacks (not forwards- or backwards-compatible with existing Lisp; and *much* slower).

    So why would anybody have ever started using Python 2.3? Because we wanted to!

  • Mark Hughes writes:
    December 5th, 20082:34 PMat

    @Jens

    Python usually keeps old branches maintained for a considerable length of time. I think there’s still critical security and date/time patches going into 1.6, which was technically “dead” in 2000.

    I expect that for some time to come, people will be using “make install” not “make fullinstall” on their systems, so new Python 3 scripts will start:

    #!/usr/bin/env python3.0

  • David writes:
    December 5th, 20082:46 PMat

    Sorry everyone, I do mostly perl and I see two comments on this page based on gross misconceptions about perl, Unicode, and Perl6. I think you *have* to read a bit more about it before spreading hearsay and false assumptions. Ok, this is not a perl article, right. But still a bit annoying to read the same things over and over again :)

  • Fred Blasdel writes:
    December 5th, 20083:09 PMat

    Or alternatively, they could have taken the opportunity to make larger changes in the language. Just off the tip of my tongue: data encapsulation (private members/methods), better syntax for operator overloading, true blocks, optional data typing…

    Truly inaccessible private members would not be pythonic.

    I don’t see there being a better syntax for operator overloading that wouldn’t obscure what’s actually happening: “/” calls __div__ on it’s left argument. Anything else would be a lie.

    Blocks would not be pythonic, go back to Ruby if multiple function types are what you want. Guido made a principled decision in python to have only one type (leads to the explicit-self thing), and that’s one of the few fundamental things that define the language.

    Syntax for type annotations is one of the new features in Python 3, though they are not yet used for anything.

  • oomu writes:
    December 5th, 20083:09 PMat

    it’s lot like PHP situations.

    python HAS to rid of old stuff. it’s an opensource project, it’s not industrial yet, it CAN fork, and if it has to do, it has to do now before there are too much pressure against.

    books is not a problem , there will be new books, old books are always deprecated. Even for C, if you consider people are using C frameworks in reality.

    my point is : they should break now instead to be totally useless in future.

    Php 4 was a mess! php 5 needed me to set up a whole new web server (parallel install ? no) but php5 really helps to improve the language. and it was absolutely necessary.

  • Bob Matsuoka writes:
    December 5th, 20083:16 PMat

    Probably worth pointing out that in the Python developer community, at least, there seems to be fairly universal support (and enthusiasm) for this approach, few worries about code migration. Contrast that with the Ruby community, which seems to be in a bit of disarray over the 1.8 - 1.9 - 2.0 transition (or the VB fiasco, as someone pointed out earlier; and made the good point that as ham-handed as that transition was, the community “more-or-less” got over it — though I’m sure it cost MS a chunk of the community).

  • Julio Biason writes:
    December 5th, 20083:17 PMat

    @Preston, @DZ:

    AFAIK, Django already runs on Python 3.0 using the 2to3 tool (and, if I’m not mistaken, you can run it passing an extra parameter to setup.py during install.)

  • Fred Blasdel writes:
    December 5th, 20083:41 PMat

    Also Jens, you do understand that every single argument you’ve made was hashed over by hundreds of people in millions of words of discussion over a period of many years (finalized in the last two). There were many thousands of contentious mailing list threads, dozens of well-thought-out alternative proposals not implemented, etc.

    This whole process was gone through once before with Python 2 — fixing the object system once and for all was absolutely necessary. Fixing encoding was similarly worth it for Py3.

  • Halo12 writes:
    December 5th, 20084:11 PMat

    Wait a second… Aren’t you plagiarizing the marketing materials for Vista??

    We’ve made a number of improvements to the system libraries. Of course, all existing apps will break, so you’ll have to get upgrades from the developers (which won’t run on earlier OS’s, by the way.) And afterwards you’ll notice everything running 10% slower! But we’re sure you’re going to love the enhancements to iterators and Unicode support…”

  • Lennart Regebro writes:
    December 5th, 20084:19 PMat

    The incompatibilities are blown up. Yes, most software will not work, but there are code conversion tools, and most conversion is simple. Also, Python 2.6 has much forward compatibility so you can run code on 2.6 and 3.0 at the same time.

    Python has NOT forked. In theory it may fork, but it has not forked yet. So saying that this pushes you to another language now is an excuse.

  • Jared writes:
    December 5th, 20084:21 PMat

    It seems your main complaint is backwards-incompatibility. I suggest you look at the changes between Ruby 1.8.6 and 1.8.7 to see all the sorts of things that break in a minor, incremental release.

  • Dethe Elza writes:
    December 5th, 20084:44 PMat

    Just a few points I’d like to make:

    1. It is totally possible to write Python code that works in Python 3 and Python 2.x

    2. Every point version of Python has broken compatibility with extensions, so extension writers have had plenty of practice porting to a new Python.

    3. The Python developers have bent over backwards to ease the transition by porting many of the 3.0 features to 2.6 and creating the 2to3 tool.

    4. The python dev team has clearly marked 3.0 as Not Ready For Production (yet)

    5. But, Python 3 has to be out there so that extension writers can start porting to it, developers can start learning the new features and porting older code, etc.

    6. Apple and Microsoft spend more attention to backwards compatibility. They are also huge corporations with lots of paid developers working on that compatibility. Python development is almost entirely a volunteer effort.

    Personally, I’m psyched that Python 3 is out. The multiprocessing module, class decorators, and consistent use of iterators and generators are all things I’ve been looking forward to for a long time. Would I like to see more in it? Sure. Would I be even happier if all my favourite extensions were already ported? Of course. I’d also like a pony, but y’know, I live in an apartment, so where would I keep it?


»  Substance:WordPress   »  Style:Ahren Ahimsa