little boxes made of words

1. On Thu, Dec 4 at 11am,
   http://openid.devklog.net/jeanfrancois said —

   Python 3 has always been slated to be backward *incompatible*. This is a good thing, in so far as Python 2.x is going to be maintained for a very long time still.

   By not imposing any compatibility requirements on Python 3, it became possible to clean up the language by completely removing features that didn’t make sense or were not properly done the first time.

   For example, there is no way the unicode cleanup could have been done without breaking a lot of existing Python applications. Shoehorning the “great unicode cleanup” in Python 2 would have created far many more problems than it would have solved.

   Deprecation is a good thing, it must happen for any piece of technology to survive. It will certainly take a long time for Python 3 to be used in large projects, but it will also be with us for at least a decade if not more. It’s important to remember the timescale of a computer language is not as short-lived as that of an application or piece of hardware.
2. On Thu, Dec 4 at 11am,
   Jens Alfke said —

   jeanfrancois — I understand the need for incompatible changes, in general. But in this case the cost/benefit ratio seems rather poor. Looking to the long term, as you say, what I see is that the Python community will now be dividing its efforts between two incompatible versions. Library developers will need to maintain parallel branches for 2.6 and 3.0 compatibility, and people working on the runtime will have to choose between putting features only into 3.0, which means few people will get benefit from them for a long time, or putting them into both branches, which will take longer.

   From a pure engineering perspective, the transition may make sense. But it’s very dangerous from a marketing perspective; and it does need to be looked at that way because there _is_ a marketplace of languages, and developers have only finite attention and effort to spend.
3. On Thu, Dec 4 at 12pm,
   Bryce Kerley said —

   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…”

   Sounds an awful lot like Mac OS X or Windows NT (basically from 3.51 until XP), in that the backwards compatibility situation kept people away.
4. On Thu, Dec 4 at 12pm,
   Chris Ryland said —

   Jens, I think the Python dev community (Guido in particular has voiced this) saw 3.0 as a chance to rebuild the foundations of the language slightly, in order for language development to move ahead.

   Sorta like when you realize your house is overextending its foundations after much remodeling, so you need to lift up the house and pour a new foundation, then drop it back, which will always require some retrofitting.
5. On Thu, Dec 4 at 12pm,
   http://openid.devklog.net/jeanfrancois said —

   The improvements to the unicode situation and to the exception model alone justify the transition in my opinion. The amount of time spent ensuring proper Unicode handling in Python 2.x applications, especially in large applications that use many third-party packages and frameworks, is prohibitively high. All the smaller changes, from the reorganization of the standard library to the new syntax, may not provide right now a large benefit, but will allow Python 3 to be evolved more productively over the coming years.

   In other words, I consider Python 3 to be a long-term strategic release, much like Objective-C 2 and the garbage collector in 10.5. Most applications in 10.5 do not use either one of those technologies, but they were released in the 10.5 timeframe to establish a new foundation to support the growth of future applications and OS releases.

   Furthermore, I do not think the development overhead on the Python core developers is that significant. It is certainly real, but Python 3 and Python 2 have been in concurrent development for a few years now, and we have continued to see quality releases of the Python 2.x line.

   Finally, I’m not sure the marketing argument stands either. Python 2.x is going to remain available and maintained for years. Why would Python 3 affect Python 2’s mindshare in any ways? I do not see a project lead during infancy asking himself “What are the reasons for and against using Python 2 for this project?” and putting Python 3 in the “against” column. A similar argument can be made for Python 3.
6. On Thu, Dec 4 at 12pm,
   Jens Alfke said —

   Bryce— I don’t think the OS analogy holds. Whenever Apple’s made incompatible transitions (68K–PPC–x86, System 6–System 7, OS 9–OS X) it’s put a lot of work into backward compatibility, so people could still run their old apps. For the simple reason that each transition would have failed completely otherwise, with customers staying away, causing developers to stay away.
7. On Thu, Dec 4 at 12pm,
   Michael H. said —

   I don’t know if it really helps, but it seems like they’ve provided a “2to3″ tool to convert Python 2.x code to Python 3, so that you don’t have to deal with those xrange()’s yourself.
8. On Thu, Dec 4 at 12pm,
   Bob Matsuoka said —

   I think you’re missing the point a bit. 3.0 should be seen as a fork more than a new release. Future upgrades and enhancements will mostly happen to the 3x branch. If you’re happy with the 2.x branch, you can stay with it. 2.x will probably have some improvements as well, but more maintenance and incremental. The motivation to upgrade is not the features in 3.0 per se, but the opportunity to take advantage of the language going forward.
9. On Thu, Dec 4 at 12pm,
   vja2 (LJ) said —

   Python 2.6 was intended as a transitional version. I think the idea was that developers would make their code 2.6 compliant, and then run the automate 2to3 tool to convert to version 3.0. So, in effect, 2.6 is the backward compatibility. Any code written for 2.6 should be relatively easy to translate to 3.0.

   I think this is actually more akin to what KDE has done: they had a clean break with the 3.x series in order to prepare a foundation that future work could be based on. They’ve taken flack for it, but I the results so far have been fascinating.
10. On Thu, Dec 4 at 12pm,
    http://toxicsoftware.com/schwa said —

    For me the “once and for all” Unicode fixes are a deal breaker. I’ve been bitten by constant encoding problems in python
11. On Thu, Dec 4 at 1pm,
    http://shadytrees.myopenid.com/ said —

    If you don’t fix the small problems, you’ll one day wake up and find that you can’t fix the big ones. Look at the massive effort that’s gone into ridding Perl 5 quirks and oddities (all small problems that aggregate into a big headache) in Perl 6, for example.
12. On Thu, Dec 4 at 2pm,
    Jonathan Wight said —

    Grrr. Jen’s blog chew my message up 1/2 way through and wont let me repost on top of that I mispoke in my last comment. Please ignore.
13. On Thu, Dec 4 at 2pm,
    Julio Biason said —

    1) 3.0 is 10% slower because of the change from ints to longs. If you read it carefully, they mention that there is space for improvement, but they want to have it out so people can start to use and see the differences. Release early, release often (and it took 3 years to get there, so better do this once and for all.)

    2) Python’s moto “There should be one — and preferably only one — obvious way to do it” went full swing in this release. Most of the duplicate features were removed, so the language is more consistent now.

    3) Claiming that books are out-of-date is, well, too shallow. Any new software version will make books about that topic obsolete (or would you say that the new features in Ruby 1.9 are not worth using and so using old books are fine?)

    4) The conversion tool, “2to3.py” analyzes the AST, not your code. It means it will try to *understand* what you are trying to do, not what your code says. It may not be perfect, but will be better than most of conversion tools based on code.
14. On Thu, Dec 4 at 2pm,
    Jens Alfke said —

    Julio— There’s a difference between a book that doesn’t cover the newest features, and a book that describes things that no longer exist or have changed incompatibly. The former is still useful, like the 1st edition of the Ruby “pickaxe” book. The latter is nearly useless.

    Regarding your points #1 and #2: The combination of these implies that aesthetic purity is more important than performance or compatibility. That’s a dangerous attitude, IMHO, at least from the standpoint of developer adoption.
15. On Thu, Dec 4 at 3pm,
    Bob Matsuoka said —

    “aesthetic purity is more important than performance or compatibility”

    Again, I think you’re missing the forest for the trees. Microsoft deliberately sacrificed long-term performance for short-term compatibility issues, and have suffered enormously as a result. The purpose of a fork like this is to improve long term performance over short-term compatibility. This is far from aesthetics — the perl example is particularly apt. Building on a flawed code-base is the quickest way to obsolescence.

    Over the long term, the performance of the language as a whole will improve dramatically, and IMO so will developer adoption.
16. On Thu, Dec 4 at 6pm,
    Julio Biason said —

    Just a couple more points (’cause I just saw the presentation of Python 2.5 release manager):

    “Programming in Python 3.0″, the book, should be available in US in 1 month. Also, part of the incompatibiles come from a smaller bytecode opcodes, which should make the code faster to load (and, again, there was no work in optimizing numerical operations yet.)

    Also, I was seeing the conversion results for a simple Pyhton code (a brainf**k-like language) and most of the conversions were things no one should be using anymore (like xreadlines and has_keys()) ’cause there were simpler solutions already (a file object is an iteration in itself, you can ask if a key is “in” a dictionary) since Python 2.2 and that’s when I realized I don’t use xrange (or range) since that version. Most of the time, you’re iteration around lists and dictionarys and you can simply run a “for item in list” or “for key in dictionary”, which makes range() and xrange() not so useful anymore.
17. On Thu, Dec 4 at 7pm,
    Julio Biason said —

    Just to complement Bob comment, Python 3.0 is not the replacement for the Python 2.x. Well, it is, but not *right* *now*. Python 2.x will still be maintained, with a Python 2.6.1 nearby, a 2.5.3 should be release to fix some security issues soon (well, as soon as the 2.6.x release manager and the 2.5.x release manager finish their talks in OSDC ;)), a 2.7 with further information about things you should change in your code for 3.0 should appear in a space of 6 months, with a following 3.0.1 and a 3.1 release planned for a space of 12 months.

    So, as you can see, it’s not a case of “it’s incompatible and all your code is obsolete right now.” Is more of “it’s incompatible but we’ll provide a gentle upgrade path for your applications” And remember that you can have different Python versions installed at the same time in a system (that’s good and bad, I know, but at least it doesn’t mean you have to keep jumping between versions when your application stops working.)
18. On Fri, Dec 5 at 10am,
    Brad J said —

    I do most of my professional development in Java these days. For almost ten years, I’ve been saying one of the biggest problems in Java is that they’ve been unwilling to make this sort of break - to clean up all the loose ends in their API caused by the discovery that, hey, maybe this wasn’t the right approach after all.

    Yes, right now, it’s minor cleanup. But, given time, you end up with three or four “right way”s to do everything, and you can’t just use the newest because the old one is embedded in some old APIs, so you need adapters and connectors and conversions. (For this drawn to absurd extremes, look at Java’s ‘Date’ class, which is basically deprecated for almost every use, but can’t go away because (among other things) it’s the superclass of the SQL interface’s Date class.)
19. On Fri, Dec 5 at 10am,
    Paul Hoffman said —

    Unicode done right. That is sufficient for most of us. Perl blew it totally, Python 2 blew it totally, Ruby and Java mostly blow it. Having a programming language that gets text handling right is worth it.

    If 2to3 works reasonably well, people who want to do 3 can do so with probably not a lot of cleanup effort (and Python code is more readable than Perl, or so they say).
20. On Fri, Dec 5 at 10am,
    Eric said —

    Julio:

    It’s not that there will be a “gentle upgrade path” python 2 and python 3 will always be incompatible languages. So now you have .py files, you need two complete sets of python to be sure to run that code. You will always need a python 2 interpreter to run older code and if python 3 actually takes off you will need a newer interpreter as well.

    How many .py scripts start with #!/usr/bin/env python?

    Right now most scripting languages suck. The reason python has sucked less is because of library and add-on support, which this breaks. Unicode clean is great, but this is essentially a whole new language that looks like python. How long before a majority of these libraries jump to python 3+? How many of these libraries can support the development and maintain of two, incompatible, branches?
21. On Fri, Dec 5 at 11am,
    Jason said —

    Ahh, the classic “I’m not flaming, here” flame. All the new features are “minor”, save the completely revamped Unicode support, but even that is merely “less confusing” - no, you’re not flaming at all. I mean, what, exactly, are you looking for as an answer, here?

    For instance, the performance question: several people have pointed out that the Python folks chose to ship something people could start using rather than do all the performance tweaks up front, and that performance is expected to improve as a basically known roadmap is followed going forward. This reasoned tradeoff might not be ideal, but for you it represents part of a “dangerous attitude” that a dynamic scripting language might ought to value clarity over performance. And the comparison to Ruby 1.9: nevermind that “three times as fast” as 1.8 just puts things at par.
22. On Fri, Dec 5 at 11am,
    Nick said —

    So yes, Apple put a lot more work into backwards compatibility but in a sense it was work they had to do to keep customers. As an open-source community, Python doesn’t have as strong a pressure to do that and I think therefore the idea is to look forward, rather than backwards.

    I think your argument comes down to “preemptive multitasking and protected memory were worth the pain of Mac OS X 10.0, is the removal of features and a cleaner language such a win here?” I think the answer is intially “no” but in the future, probably yes.

    From a user (i.e. programmer) point of view, removing all the edge cases and deprecated features make python a simpler language to learn and use. More importantly, though, from a technological point of view Python stands to benefit from being a smaller, more consistent language. There is a lot of research in dynamic languages these days which python stands to benefit from. By tightening down and throwing off lots of useless baggage, it will be sooner be able to take advantage of the latest in JIT technology.
23. On Fri, Dec 5 at 11am,
    http://www.blueskyonmars.com/ said —

    You can’t look at the Python 3.0 release without also considering Python 2.6. Python 2.6 gives you most of 3.0’s features today, plus a whole bunch of tools and tricks to make your code work in 3.0. Python 2.6 also provides the standard backwards compatibility that all of the 2.x releases have had (in other words: moving to 2.6 is no big deal).

    2.6 provides:

    * a bunch of __future__ imports that bring in new 3.0 keywords and changes
    * a warnings mode to tell you about things you’re doing that are not compatible with Python 3.0
    * the 2to3 tool that automatically does many conversions for you.

    The unicode handling is the trickiest part.

    Once it gets to the point where library authors say “Python 2.6 or greater required”, then it will be an easier step up to 3.0 (because library authors will be able to do all sorts of stuff to enable their programs to work well in both Python 2.6+ and 3.0+).

    So, Python 3.0 is here, but no one is really going to use it. The point really revolves more around Python 2.7 or 2.8 and 3.1 or 3.2. Somewhere around there, people will start making the leap to the 3.x line and the Python developers will have had a better base to work from on those 3.x features.
24. On Fri, Dec 5 at 11am,
    Bob Bobmore said —

    Interesting that nobody (so far) has offered an appeal other than “eat your veggies, it’s good for you.” This leads me to conclude that Py3 is largely an academic release and can be ignored by those of us who use Python but aren’t programming language geeks and just have to get work done.
25. On Fri, Dec 5 at 11am,
    Jens Alfke said —

    Bob — I’ve come to the exact same conclusion. Python 3.0 sounds like it’s great for the Python implementors themselves, and for the language lawyers. It should have been labeled a “Technology Preview”: something to take a look at as an indication of future directions, and for people who maintain libraries to work on compatibility with.

    It’s weird how most of the people commenting don’t seem to get that there are factors other than academic ones involved. There is a marketplace for languages, and those that do less well at attracting developers tend to dwindle. Look at LISP — very much ahead of its time, but in focusing so much on the purity of the language, and refusing to make compromises that would make its syntax more approachable or readable, they doomed it to be marginalized.

    Python 3 is actually probably going to tip me more toward Ruby for future development. Ruby has its issues, but at least it’s not forked, so I won’t have to throw out any books, and once the minor 1.9 compatibility roadbump is past I won’t have to worry about which library is compatible with which flavor of the language.
26. On Fri, Dec 5 at 11am,
    Preston said —

    I think that the situation in Drupal land has some informative bits here, there has always been the emphasis on a migration path for data, but not code:

    http://drupal.org/node/65922

    While this is great for the core people and aesthetic purists it can suck for those who are developing with the tool when trying to take advantage of the ecosystem of extensions and documentation.

    A quote that might apply to both Drupal and Python is:

    “Its the modules stupid!”

    So much of the value is in taking advantage of some already solved problem. Often the author’s or maintainers of a module are no longer around when the terrain in the core shifts and a module never gets updated (at least not in a timely manner).

    I do think that the python crew should look into somehow building in the 2to3 tool into the interpreter - something like 68K emulation, or Rosetta. Sure such a inline conversion would slow things down - but it would be a lot less of an impact than having to go and upgrade/debug/convert/maintain someone else’s module. I’m not saying this would be technically easy - but to be blunt - its not my problem, as an end “user/developer” I want to go where I’m most productive.

    Another point worth mentioning - is this may hamper the Django hosting ecosystem, as hosts have to decide when to switch.
27. On Fri, Dec 5 at 12pm,
    Matt J. said —

    I think the transition will be just fine. Look at what happened when microsoft abandoned VB6 in favor of moving their developers over to .NET. It was a no brainer, yet people who had maintained VB6 software stacks went apeshit. They suddenly had to migrate over to a new backend that most definitely broke their code in non-easy to fix ways. It took many many many years for companies to transition off of VB6, but it happened.

    True, this made an opportunity for developers to try something completely different, like Java. However, Visual Basic never came with a promise to remain backward compatible for the next decade or more. Companies that invested resources into building apps on top of VB simply took that risk.

    You can also say the same thing about the entire multi-row section at Borders/B&N that sold VB6 books. All worthless overnight! Or what about the enormous 3rd party ActiveX control industry that suddenly became obsolete?!
28. On Fri, Dec 5 at 12pm,
    DZ said —

    Preston:

    “Another point worth mentioning - is this may hamper the Django hosting ecosystem, as hosts have to decide when to switch.”

    There’s nothing stopping hosts from having both Python 2.6 and Python 3, and any number versions of Django. The same thing happened with Rails 2. This isn’t like some sort of thing where it’s all or nothing in one direction.
29. On Fri, Dec 5 at 12pm,
    DZ said —

    Bob/Jens:

    (Proper) Unicode support is a Big Deal, so I’m confused as to why you both think this is a pure “academic” release.

    Sure, there might not be as many new things as you would like, but it’s equally disingenuous to pretend that there are *no* features that are of practical worth.
30. On Fri, Dec 5 at 12pm,
    Eric said —

    DZ, maybe the cost of a very non-trivial upgrade is far most expensive that making unicode work “well enough” in python 2. In the end unicode is only major non-academic feature.
31. On Fri, Dec 5 at 12pm,
    Mark Hughes said —

    The hostile tone here is really not productive, Jens.

    There are 3 current and future Python versions, for different purposes:

    2.5.x: Maintenance release for existing code with no changes.

    2.6.x: Update release for improving existing code, but not making any great leaps. This will be followed by 2.7, a final maintenance branch for 2.x.

    3.x: Entirely new version that finally fixes Unicode and some other design flaws. New apps should be written in 3, or at least it should be strongly considered.

    Your existing code WILL NOT BREAK if you stick with the 2.x line, which will be supported for a year or more. For that matter, there’s still old code running on 1.6. It works for those people.

    Now, when you feel like joining the future instead of just importing it.

    Correct Unicode support alone would make 3.0 a worthwhile upgrade, and there’s a lot more to it than that. It takes a small performance hit for doing Unicode and correct number handling. What else do you want, a pony?
32. On Fri, Dec 5 at 1pm,
    Jens Alfke said —

    DZ— It’s true that multiple versions of Python can coexist, but it means hunting down and eradicating all those “#! /usr/bin/env python” shebang lines. I just looked in my Django sources, and it seems to add those in apps it creates.
    By comparison, both Rails 1.x and 2.x run under Ruby 1.8, so there wasn’t a need to switch interpreters.

    Unicode support is a big deal. I guess I haven’t used Python deeply enough to run into the serious UC issues some people say are there; or I’ve been working with higher-level libraries that worked around them for me.

    Since there was already a UnicodeString class, I don’t understand why incompatible language changes were needed to fix these problems. I totally agree that, in the abstract, the new str-vs-bytes design is much better (it’s much like NSString vs NSData in Cocoa.) But it’s going to break so. much. code. And I don’t see how a magic source converter tool is going to understand code well enough to do this refactoring automatically, not in a language as dynamic as Python. (How does it know whether a call to J. Random Method returns an encoded or a Unicode string?)
33. On Fri, Dec 5 at 1pm,
    jaharmi.pip.verisignlabs.com said —
    
    
34. On Fri, Dec 5 at 1pm,
    MattB said —

    “Ruby has its issues, but at least it’s not forked, so I won’t have to throw out any books”

    This is a significant exaggeration. The delta between Python 2.x and 3.0 is just not that large. Our team digested the “What’s New” document and we’ve all got in our heads the important differences, and frankly it wasn’t taxing.

    Go read the canonical Python tutorial for 3.0–or better yet, diff it with the RST source for 2.6 or 2.5. You’re right–there aren’t a lot of deltas.

    We’re not using Python 3.0 yet either. At least not until numpy catches up. The lag with third-party modules is a fair point to make, and it’s what will keep most of us from upgrading to Python 3.0. But the language changes were decided upon by the Python community over a long and open process we all could have input to, and in the end wound up much less profound than had been planned.
35. On Fri, Dec 5 at 1pm,
    Nick said —

    I think this comes down to the nuanced issue of exactly how different Python 3.0 is from Python 2.6. The pain point is when the incompatibility is great while the benefits are not.

    It seems to me that the reality is that python 3 is only mildly incompatible with Python 2.6. So yes, the new features aren’t earth shattering, but at the same time I don’t think porting will be that difficult—the vast majority of changes were in removing the “old ways” of doing things, which you ought to be doing to your code anyway.

    The other point is that this is 3.0 (much like Mac OS X is 10.0). In our industry, we’ve seen that something tends to happen to successful software when it gets to about its 6th or 7th major revision. At some point, success gets to be a burden that prevents future forward progress. Good backwards compatibility should be commended, because it is damn hard, but at the same time it can lead to debacles like Copland and Vista.

    So looking at Python 2.6 and 3.0, it seems clear that 2.6 is the right choice for most. But in a few years the choice will be between python 2.6 vs. 3.3 and I think Python 3.3 will win for most people. The alternative is to wait a few years and be faced with Python 2.9 vs. 3.0.
36. On Fri, Dec 5 at 1pm,
    Jens Alfke said —

    Mark — I’m really trying not to sound hostile! But I’m disappointed, and I’m feeling like the Python community is shooting itself in the foot and hasn’t realized it yet.

    I totally understand about existing code not breaking. However, as you point out, in a year or so it’ll be running on a deprecated/unsupported/EOL runtime. That’s not what any developer wants to hear. First, there’s the spectre of urgent Python patches (security fixes, OS compatibility, etc.) that will only be done for 3.0. Second, the app may use libraries that cease development for 2.x, making important fixes only available to clients that use 3.x.

    But the alternative is to port your own code to 3.0, plus get new ported versions of every library you use (plus the transitive closure), then do the integration work to make sure everything still works. For example, what happens if my app uses FooLib 1.5, but the Foo developers are only doing the Python3 port as part of the new FooLib 2.0 release, whose API is incompatible with 1.5? Then I not only have to deal with Python 2-to-3 but also FooLib 1.5-to-2 at the same time.
37. On Fri, Dec 5 at 1pm,
    Jens Alfke said —

    Nick— “I don’t think porting will be that difficult—the vast majority of changes were in removing the “old ways” of doing things, which you ought to be doing to your code anyway.”

    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.
38. On Fri, Dec 5 at 1pm,
    Frank said —

    It will run some existing python programs. You’re over exaggerating the changes that need to be made. There is nothing fundamental that breaks everything. The converter is actually pretty good too.

    The books argument is a bit disingenuous. Especially if you’re pointing at Ruby, how many of the first edition Rails books are still good beyond that “this is how you get started.” Things change, books get out of date, that’s life. Many of the fundamental of the Python language are still correct, certain specific functions and classes have been altered but it’s not like you’re learning a new language. Huge chunks of the library are essentially the same and that’s where I’d expect the most pain to be.

    You can rationalize the 3.0 release as a transition release or something, it’s the future of the language and there was a community process you could have been involved with. 2.x isn’t going to just die but in 5 years or some number x years when we refer to Python, we’ll be referring to a post 3.0 python. Sometimes you have to go backwards to go forwards. Look at C++ and what they got for refusing to cut anything out. Sure, things like xrange, are annoying but there is a direct replacement in range, it has said xrange is platform specific in the docs for who knows how long, the far better question is why range wasn’t fixed eons ago when xrange was added. Something like print is probably more annoying but it is very easy to fix.

    Dive in and change some programs, it’s not to hard to get them 3.0 ready
39. On Fri, Dec 5 at 1pm,
    Sharkey said —

    It’s weird how most of the people commenting don’t seem to get that there are factors other than academic ones involved. There is a marketplace for languages, and those that do less well at attracting developers tend to dwindle. Look at LISP — very much ahead of its time, but in focusing so much on the purity of the language, and refusing to make compromises that would make its syntax more approachable or readable, they doomed it to be marginalized.

    This might paint me as an academic or language lawyer or whatever, but sometimes it’s good to ignore the software developer market and just Do What’s Right. There were some warts in Python, some of them possible to ignore (range vs xrange) but some weren’t (problems with non-local but non-global scoping). The job of the BDFL is not to increase shareholder value, his job is to make Python the best language possible according to his perspective. If that requires a compatibility-breaking release, so be it. If that dooms it to being “marginalized” like Lisp, so be it.

    Your post implies that the best language is the one with the most developers. I disagree with that implication strongly (but that might be because I code in Piet :) )
40. On Fri, Dec 5 at 1pm,
    Doug Napoleone said —

    On the 2.x line there were many improvements to the AST, bytecode generation, and namespace runtime (MRO - method resolution order). Many new algorithms were developed as part of the PyPy project which used a subset of the python language. Python was running into problems on large grid installs due to the module import system which needed a rewrite to resolve (bootstrapping is hard).

    None of these improvements could be implemented in CPython due to old decisions, __getattributes__ v.s. __getattr__, strings being bytes, old style classes, the list goes on.

    There needed to be a break, and to remove the things which were blocking forward momentum. When you make that break you have 3 options:

    1. try to somehow still support all the old stuff
    2. provide a system for migration
    3. ignore the issue, and just tell people to deal with it.

    Similarly, for getting th first release out the door you can:

    1. release something early but stable, but without any/many improvements so that people can work on adoption; and then move forward with all the previously gated issues later.

    2. release something later, with tons of new bells and whistles and improvements, but leave a cloud of migration and uncertainty. Also fracture your development efforts between fixing the problems which were holding you back, and developing those new and great things.

    Anyone who has any experience with refactoring a software project knows that trying to develop the new features at the same time as refactoring the code which is stopping you from developing those features is doomed to failure at best.

    So I guess Python3.0 doesn’t offer too much over the 2.x line except a cleaner language, real unicode support, real binary data management, real abstract base classes, real process management, a clean IO subsystem, access to the AST, a solid migration path, an easier time for 3rd party packages to get migrated over, is easier to integrate into other programs, and now can support the implementation of many of the improvements seen in PyPy, Jython, and IronPython.

    I understand that none of those things are interesting to you in your use of python. That is fine. Just wait for python 3.1 and 3.2 for the things you are interested in.
41. On Fri, Dec 5 at 1pm,
    Steve Johnson said —

    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.
42. On Fri, Dec 5 at 1pm,
    Jason said —

    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?
43. On Fri, Dec 5 at 1pm,
    Jens Alfke said —

    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.
44. On Fri, Dec 5 at 1pm,
    Eric said —

    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.
45. On Fri, Dec 5 at 1pm,
    Jens Alfke said —

    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?”
46. On Fri, Dec 5 at 1pm,
    Nick said —

    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.
47. On Fri, Dec 5 at 1pm,
    Raymond said —

    Several Python books are being updated for 3.0 and will be out before long.
48. On Fri, Dec 5 at 2pm,
    Jason said —

    @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?
49. On Fri, Dec 5 at 2pm,
    John said —

    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!
50. On Fri, Dec 5 at 2pm,
    Mark Hughes said —

    @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
51. On Fri, Dec 5 at 2pm,
    David said —

    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 :)
52. On Fri, Dec 5 at 3pm,
    Fred Blasdel said —

    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.
53. On Fri, Dec 5 at 3pm,
    oomu said —

    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.
54. On Fri, Dec 5 at 3pm,
    Bob Matsuoka said —

    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).
55. On Fri, Dec 5 at 3pm,
    Julio Biason said —

    @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.)
56. On Fri, Dec 5 at 3pm,
    Fred Blasdel said —

    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.
57. On Fri, Dec 5 at 4pm,
    Halo12 said —

    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…”
58. On Fri, Dec 5 at 4pm,
    Lennart Regebro said —

    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.
59. On Fri, Dec 5 at 4pm,
    Jared said —

    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.
60. On Fri, Dec 5 at 4pm,
    Dethe Elza said —

    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?
61. On Fri, Dec 5 at 4pm,
    Christopher Lenz said —

    Jens, as a Python developer I think your comments on this are valid and important. I remember some of these points (especially the forking of the Python community) being brought up long before the Python 3.0 release, but I feel they haven’t been listened to as much as they would’ve deserved.

    My own thoughts on Python 3.0 release here: http://www.cmlenz.net/archives/2008/12/py3k.
62. On Fri, Dec 5 at 4pm,
    Michael Watkins said —

    It seems to me that many of the comments being made here are likely to have been made without benefit of any real experience in Python 3 or porting to same.

    I’ve just finished doing some testing in support of a web application development framework and object database package(s) which in its latest release this week to coincide with Python 3 now supports Python >= 2.4 and yes, that means Python 3 as well. Same code. And it wasn’t messy at all.

    It was a pretty clean base of code beforehand, which has certainly made it easier to move it to 3.0 compatibility. Preserving performance is a big, wet, red herring, depending of course on what you use the language for. In my case, Python 3 turns in performance equal to 2.5.x which I run on our production machines (although not for much longer).

    (your mileage may vary)
63. On Fri, Dec 5 at 5pm,
    Michael Watkins said —

    BTW my comment above was not directed at Christopher. His comment in his journal entry about third party applications and libraries is dead on.

    (and I think part of my post got truncated - see http://mikewatkins.ca/2008/12/05/why-python-3/ for a discussion on why I think performance is something of a red herring, at least for some applications)

    I particularly miss documentation tools such as docutils, pygments - hopefully there is a move to see them show up in compatible for forked versions.
64. On Fri, Dec 5 at 5pm,
    npiaseck.pip.verisignlabs.com said —
    
    
65. On Fri, Dec 5 at 5pm,
    Lennart Regebro said —

    “but I feel they haven’t been listened to as much as they would’ve deserved.”

    I was worried about this too, and that was the feeling I got when it was discussed. But that fact is that after the big discussions about this, much more backwards compatibility has been put into 2.6, and when I pointed out the last major hurdle for a smoother transition and 2.6+3.0 compatibility, that was fixed with a new future import in 2.6 within a week or so after I reported it.

    I also then the points are important and valid. But I think they have been addressed. It is perfectly possible to make a transition from Puthon 2.5 to 3.0 via 2.6 and support two python versions at a time, from the same code base.

    A fully testable set of code examples is here: http://code.google.com/p/python-incompatibility/
    It’s not complete, and I very much welcome contributions.
66. On Fri, Dec 5 at 6pm,
    Giacomo said —

    Er, this post is the definition of “concern trolling”. 2.x is still going to be updated (including “security fixes”) for a long time, anybody who actually used the 2to3 tool in the last YEAR agree that it works very well, and you have another YEAR to start thinking about porting. As somebody else pointed out, even a big app like Django already works with it, and they introduced the compatibility right in the middle of a huge release push. As *major* language transitions go, this is pretty darn sweet, and it was announced and planned well in advance. Hell, Mak Summerfield had the “Programming in Python 3.0″ book ready 9 months ago, and he’s not even a developer or an “insider”!

    Thanks for the stop-energy anyway, I could have recharged a Prius with it :)
67. On Fri, Dec 5 at 7pm,
    Michael Watkins said —

    Here’s what one group did to “port” (co-exist) their 2.x applications such that the same code base runs on 2 and 3.

    http://mail.mems-exchange.org/durusmail/qp/441/
68. On Fri, Dec 5 at 7pm,
    Thomas H. Ptacek said —

    I like this “it’s totally possible to write code that works in 2.x and 3″ argument, which GvR himself has taken the time to refute: the what’s-new doc specifically instructs developers not to do that.
69. On Fri, Dec 5 at 7pm,
    patrick said —

    Your comparisons are entirely unfair for a start. Operating systems generally are not fully backwards compatible. If you upgrade glibc, you will have to recompile your software, and there can be problems. Every major release of Windows has been a bit slower than the last version and quite backwards incompatible to boot. Every release of OSX has given people major headaches with what things they put in or took out from the previous version.

    And then comparing to Ruby 1.9 - just going by the version number makes it clear that these aren’t the same type of release in the slightest. 1.9 infers that it is most likely the final and most polished release of the 1.0 line, intended to be backwards compatible, and optimized as much as it possibly can be. 3.0 on the other hand, is a bold step in a new direction. No it’s not perfect. Sure there are flaws. That is what 3.1 and 3.2 are for.
70. On Fri, Dec 5 at 8pm,
    Colin Barrett said —

    I believe the 2to3 tool is supposed to help with the migration significantly.

    I would also speculate that it will be much easier to start a new project in Python 3, rather than convert your old ones over. Similar to garbage collection in Objective-C.
71. On Fri, Dec 5 at 8pm,
    Kcirtap said —

    @patrick: Actually, no, Ruby uses the old Linux version number model. 1.9, being an odd-numbered release, is an experimental branch. 1.8 is currently stable, and 2.0 is the next stable branch. Someone up the thread claims there’s some confusion about this within the Ruby community; I’ve not seen any, it’s been sold this way from the start.

    Ruby 1.9 is exactly equivalent in release status to Python 3.0 if what you are saying about Python 3.0 is true.

    And I can’t make heads or tails out of your “OSX major headaches” comment. I assume you’re a Windows user?
72. On Fri, Dec 5 at 8pm,
    Kcirtap said —

    I guess I should add that I’m as impressed as Jens is with the new language — this is what you break compatibility for? Really?
73. On Fri, Dec 5 at 10pm,
    http://shawn.medero.net/id said —

    This leads me to conclude that Py3 is largely an academic release and can be ignored by those of us who use Python but aren’t programming language geeks and just have to get work done.

    /me shakes head. Unicode is a *real world*, everyday problem, that tons of us have to deal with. Some of us are parsing terabytes of text data with Python… and Unicode has been a *huge* pain point.
74. On Sat, Dec 6 at 12am,
    Joe Cooper said —

    So, one of these comments mentioned Perl as being an example of Unicode done wrong, and I can’t bring myself to let that kind of misinformation stand uncorrected.

    Perl has had almost magically great Unicode support since version 5.8, many years ago, and far better than Python until 3.0 (and without breaking backward compatibility). A Unicode string in Perl is…a string. All data types can contain Unicode transparently, and you never have to think about Unicode, at all, unless you’re interfacing at the binary level with other Unicode speaking software and you need to all agree on an encoding, in which case the “use utf8″ pragma (and related pragmas) make it as close to automatic as can ever be expected. You can even write code in Unicode in Perl, if that’s what floats your boat.

    Perl has its flaws but Unicode support is definitely not one of them. It is one of the things that I would say, with confidence, that Perl got right many years earlier than Python or Ruby.
75. On Sat, Dec 6 at 2am,
    Lennart Regebro said —

    “GvR himself has taken the time to refute: the what’s-new doc specifically instructs developers not to do that.”

    In fact, that documentation is outdated and incorrect. It for example says that you have to avoid using print, which was true a year ago, but is not true any longer, after from__future__ import print_function was implemented.

    So that is a bug in the documentation, quite simply. I’ll submit a bug report. As mentioned above, I have a project to document the incompatibilities and provide workarounds. I have so far not found anything that is NOT possible to make work under both 2.6 and 3.0, although admittedly, it’s not complete yet.

    http://code.google.com/p/python-incompatibility/
76. On Sat, Dec 6 at 9am,
    LS said —

    Just to congratulate the site and its readers.

    The site: very interesting, sober and clean design.
    The community of readers: is not frequently to find such an interesting, educated and civilized discussion of ideas.

    It is a pleasure to read this comment thread.

    Thank you.
77. On Sat, Dec 6 at 10am,
    Nathan Duran said —

    Guido can do whatever he wants with his language, but I do wish he’d stop hiding behind that “one obvious way” mantra he trots out as justification for some of his more ridiculous decisions to be different just for being different’s sake. Where were you the first time you had to delete a directory in Python? How obvious was the solution?

    Like every other kid who walked around school memorizing a dog eared copy of “All The Words,” he wants to be noticed more than he wants to make anyone else’s life easier, and any form of negative feedback received as a result is reinterpreted by his ego as affirmation of some divine mandate. Praise is touted as evidence of Python’s superiority, and critics “just don’t get it” thereby proving the Python way superior again. No point in arguing; like it or lump it.

    Either way, nobody’s forcing anyone to use 3.0 and I’m sure the “Django Ecosystem” will get along about as well as it ever has. If you’re unhappy with the directions the project is taking just wait five years and something else will come along that makes some other fat guy with a stupid haircut start espousing drivel like “We will never be able to make real progress in computing and language design in our industry until Python/Ruby/Ocaml/Lua/Erlang syntax is wholly eradicated.” There was a universe before Python, and there will be one long after it’s gone. Use it for what it’s good for and put it away when you’re done.
78. On Sat, Dec 6 at 10am,
    Lennart Regebro said —

    The first time I ever needed to remove a directory in python was just now (I usually store my data in ZODB).

    So, I create a directory with lots of files in it, and to make it more difficult, subdirectorries, with files, and start up python.

    >>> import os

    A dir of os provides a removedirs method, that complains that the directory is not empty. OK. Fine. There is also a os.listdir. So, I dir(os.path) and find an isdir method. An obvious solution appears:

    >>> import os
    >>> def removetree(path):
    … for filename in os.listdir(path):
    … filepath = os.path.join(path, filename)
    … if os.path.isdir(filepath):
    … removetree(filepath)
    … else:
    … os.unlink(filepath)
    … os.removedirs(filepath)

    >>> removetree(’removeme’)

    That worked. I did one mistake, in the first typing in of it, I put the os.removedirs inside the is is os.isdir tests, so the top directory didn’t get removed. Other than that, my first try worked straight off. It took me just a couple of minutes to do this, test it and wrote this comment.

    Code speaks.
79. On Sat, Dec 6 at 1pm,
    Paul Boddie said —

    Unicode done right. That is sufficient for most of us. Perl blew it totally, Python 2 blew it totally

    Totally? Really? This is just the kind of convenient misinformation that obstructs any dialogue involving criticism of Python 3. It’s a bit like people saying that there was no convenient way to get an abstract syntax tree in Python versions before 2.6. Total fiction!

    So I guess Python3.0 doesn’t offer too much over the 2.x line except a cleaner language, real unicode support

    In what way was Python 2.x Unicode support not “real”?

    Python has NOT forked.

    Of course it has! Python 2.x and 3.x are divergent code bases. People will try and backport stuff to Python 2.7 in order to persuade people to really start using 3.0, but we’re talking about two different languages with decreasingly related implementations from now on.
80. On Sat, Dec 6 at 1pm,
    Lennart Regebro said —

    As you yourself mention, there will be more backports. So in fact, they will have *increasingly* related implementations from now on.

    And it’s not two different languages. There are a set of changes done that are done in a backwards incompatible way. That doesn’t make it two different languages. The languages does not fork, unless the community forks. That *is* a risk but one that has been greatly reduced with the possibility of gradual migrations via 2.6 (and maybe 2.7). And it has in any case not happened yet,
81. On Sat, Dec 6 at 4pm,
    Paul Boddie said —

    As you yourself mention, there will be more backports. So in fact, they will have *increasingly* related implementations from now on.

    This assumes that all major enhancements to the Python 3.x implementation will be backported, which I seriously doubt will be the case. There will come a time when people will decide that it’s not worth backporting stuff to 2.x, the hope being that no-one will care about 2.x at that point.

    And it’s not two different languages. There are a set of changes done that are done in a backwards incompatible way. That doesn’t make it two different languages.

    What should we call them, then? Dialects? I don’t think euphemisms soften the blow, personally.
82. On Sat, Dec 6 at 5pm,
    Patrick said —

    Thanks all for participating. All that was very interesting and I even learned some things here and there.

    Since we won’t be moving to 3.0 for a long time because we depend on a number of large libs like Numpy, Twisted, Beautiful Soup, Wx, SQLAlchemy, etc, I am only hoping that the large amount of visibility the 3.0 release is generating will get the lib developers to at least publish their 3.0 plans. I often can’t tell if they plan to get to 3.0, or when, whether it be 6mo. or 5 years. This makes me feel like I’ll wake up in three years and ask myself whether I should look at this situation again to see if it’s time to get serious about 3.0 with our codebbase or not.
83. On Sat, Dec 6 at 9pm,
    Lennart Regebro said —

    Paul: “This assumes that all major enhancements to the Python 3.x implementation will be backported”

    No, it assumes that more of the enhancements will be backported than new ones added, which is exactly what will happen.

    “There will come a time when people will decide that it’s not worth backporting stuff to 2.x, the hope being that no-one will care about 2.x at that point.”

    Yes, obviously the goal is that 2.x in the long run will become less used.

    “What should we call them, then? Dialects? I don’t think euphemisms soften the blow, personally. “

    It’s still the same language, the syntax differences are small (but incompatible). The standard library has been reorganized, but that hardly makes it a different language. Different versions of Basic has bigger differences than this. Different versions of C is more incompatible than this.

    Patrick: “This makes me feel like I’ll wake up in three years and ask myself whether I should look at this situation again to see if it’s time to get serious about 3.0 with our codebbase or not. “

    Well, one or two years, I would guess, but otherwise you are spot on.
84. On Mon, Dec 8 at 8am,
    David Daniel Hofmann said —

    my 2 cents

    You can no rely forever in something that was good enough 20 years ago

    And as always, it is just a matter of time to improve performance, and about compatibility issues, actually should be see as an opportunity to migrate to a better API :)
85. On Tue, Jan 6 at 1am,
    DRY said —

    Dear All above,

    I pray Python 3.0 be made to have good “execution speed” urgently !

    As a python user, I don’t care for some small stupid corrections that bother the super brains of the language. I just need the following in python 3.0 and its related areas of applicability:

    a) Speed
    b) Pyhton Browser plug-in like the JRE-plugin in all browsers for graphics

    Speed, Speed and Speed are important for me and majority others in application development area. I hate C code to be put in python and do a double job for speed. Thats why most people hate python. Even Psycho, pypy don’t match Java 6 speed. Perl is still in market due to speed. Ruby 1.9 is thought to be faster than earlier versions.

    I tell u an animal story. Some animals in savannah survive by shear strength (king of beasts) , some survive at both own and other’s strength, some survive by intelligence and speed, some by having great features that help them adapt to the conditions of savannah.

    Finally, there was one animal that had little physical power but was incredibly fast in catching its prey. This made it survive over a million years in savannah. That is none but Acynonyx jubatus(Cheetah). They have no fear of king of beasts due to their speed.

    In an analogy, I understand that Java is king of languages. Perl a Wild Dog (intelligence and speed), Python and Ruby as part-time scavengers - partly depend on C/Java in various applications, C/C++ as OS dependant fast languages (with features adapted for a particular OS) and now we want a language like the cheetah –> Enough power + speed.
    PHP filled that for web applications but what about non-web applications?

    Python is incredibly powerful language with smaller set of core language. It is slender and does most tasks what we want. Even though it is slender, it is suprisingly slow!!!! and most stupid authors of articles, write that –”optimize the algorithm first then identify the essential parts where there is a speed lag. Write those areas in C etc….”.
    Do, we need two different animals to kill the same prey?? Do we need to Scavenge on JVM using Jython and/or JRuby. Where is the identity gone? Two languages cannot have a “equal symbiotic” relationship due to their different development policies. Why depend much on other languages?? Java did a right thing to bring all together to one platform and is ruling (better than C#) like a king.

    Python needn’t fear java if it has faster run-time. As per animal rules, If python is not having speed nor highest power, it must survive due to a group. That is what I call python community.

    I will get back to python 3.0 only when its speed is near to Java 6. (Or atleast even if it’s speed is twice slower than Java). Python is a gr8 language with many good features but success depends on speed !!Does this get to the brains of people developing python versions!!

    Quote: “You shudnot market urself much. Other’s shud acknowledge that u r gr8″ (This is what people call Java).

    Regards,
    DRY
86. On Wed, Jan 21 at 12pm,
    rich said —

    I think cheetahs are going extinct — limited genetic diversity.

    I am not overly worried about python 3.0, happy it is being done, and will make my way over there on the slow train, after numpy etc.
87. On Fri, Feb 6 at 10pm,
    DRY said —

    >>>>>I think cheetahs are going extinct — limited genetic diversity
    Agreed for limited genetic diversity but atleast there are conservation efforts rather than wiping off. Python still doesn’t have speed. So no conservation efforts. Language will get wiped off.

    >>>>>I am not overly worried about python 3.0, happy it is being done, and >>>>>will make my way over there on the slow train, after numpy etc.
    By then you expire from job

    DRY
88. On Mon, May 4 at 6pm,
    Will S said —

    I’m a geologist (used to be a programmer in the early 90s) and I’ve been dabbling in Python for a few months…programming isn’t my primary function by any means. So far, I’ve bundled a few small programs in data releases. However, this switch from 2.x to 3.0 means that the hours I’ve invested in learning Python have been largely wasted…I don’t have time to learn new ways of doing old things (print x, print () wtf, wtp?) At this pointed, I’m opting to retain Python at my current level for simple scripting and sharpening my Java for “real” programming. I need a *stable* language - I have too much to learn and keep up with to continually relearn programming languages. I’m probably not the only one.

    Personally, I don’t think that Python is popular enough or transparent enough to maintain two separate versions that require two separate support packages.
89. On Mon, May 4 at 9pm,
    Lennart Regebro said —

    “However, this switch from 2.x to 3.0 means that the hours I’ve invested in learning Python have been largely wasted…”

    No, it doesn’t. Python 3 is not another language. It’s still the same language.

    “I don’t have time to learn new ways of doing old things (print x, print () wtf, wtp?) “

    See, you already HAVE learnt that difference.
90. On Sun, May 10 at 10pm,
    Leo Murch said —

    @DRY

    Further to your statements, I wish to add “Python has lame Optimization” and “Small Job market”.

    Some mentioned in their sites, “Pythoneers Facing mid life crisis for job”

    Leo
91. Name:
    Email:
    Website:
    Name and email are required. Thanks!
    
    [Or log in]    [Or register]

    Or use your OpenID:
    LiveJournal username DeadJournal username Other OpenID URL

    HTML: You may use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

    Notify me of followup comments via e-mail

Design: Hemingway, modified by Chris Gerlach, further modified by me, Jens.

Entries feed   Comments feed