Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Python Upgrades

Python 3.2 Released 164

Posted by CmdrTaco from the watch-out-for-teeth dept.
digitalderbs writes "Python 3.2 was released on Feb 20th 2011 with many new improvements. New features include many useful updates to the unittest module, a stable ABI for extensions, pyc repository directories, improvements to the email and ssl modules and many others. This also marks the first release in the 3000-series that is no longer backported to the 2.0-series."
This discussion has been archived. No new comments can be posted.

Python 3.2 Released More

Python 3.2 Released

Comments Filter:

  • Another great Python 3.x series release (Score:4, Insightful)

    by Anonymous Coward on Monday February 21, 2011 @09:08AM (#35267374)

    That no one will use because there is no compelling reason to port all that cool stuff developed for the 2.x series.

    • Re:Another great Python 3.x series release (Score:4, Informative)

      by MetalliQaZ ( 539913 ) on Monday February 21, 2011 @09:16AM (#35267458)

      You don't even have to click through to the article...you can find this right in the summary:

      "This also marks the first release in the 3000-series that is no longer backported to the 2.0-series."

      Python 3.x has grown up and moved out of the house, so to speak. As the language develops, 2.x will be left behind and all your favorite packages will be ported to the new language using one of the excellent automated conversion "helpers" such as 2to3. Twisted, Django, PIL, etc will eventually concentrate on 3.x, and the community will be healthier overall, having been able to shed the stuff that didn't quite make sense with Python.

      So stop complaining, sheesh!

      -d

      • Re:Another great Python 3.x series release (Score:5, Insightful)

        by Anrego ( 830717 ) * on Monday February 21, 2011 @09:39AM (#35267630)

        This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.

        I'll admit I've never developed a programming language, but I have worked on large, long term libraries, and I think the same principle applies. All those stupid design decisions and approaches that are now obsolete and make no sense.. you have to make them still work anyway. You can spew lots of warnings.. but to me breaking backwards compatibility in a _programming language_ is sloppy and completely unacceptable.

        • Re:Another great Python 3.x series release (Score:5, Insightful)

          by bjourne ( 1034822 ) on Monday February 21, 2011 @09:51AM (#35267706) Homepage Journal
          That's exactly what Python did and does, where appropriate. Where it isn't, such as the changed meaning of string literals (they are all unicode now) or the division operator, the breakage is hard. There is no way around that if you want to modernize the language. C# did it too, Java did not. Which is why generics in Java are half-assed and why there are a lot of quirks in the language that traces their roots back to version 1.1 or earlier.

          • Re: (Score:3)

            by Anrego ( 830717 ) *

            Java did not

            Probably one of the reasons it's so popular in the "serious business"[tm] crowd. I write something in Java, I know it's gonna work in 5 years without me needing to keep some legacy version of the JVM around. Stuff can be gradually migrated over to the replacements for deprecated functionality, without essentially having to fix everything before being able to migrate. See portage and many others for issues associated with the python approach.

            • At work, I currently need Jinitiator 1.3.1_02, 1.3.1.28, and 1.3.1.29 in order for all my work related java applications to work properly. I tried just using the new one and most of my apps won't even launch.

              • Yes that kind of problem is very real and annoying. But in the Java case is mostly an implementation problem, not the result of a conscious decision to break everything. Also, IMO that issue was less frequent in recent years, at least with the mayor JVM implementations.

            • That's the classic red herring argument.

              In five or ten years from now, the python VM of the particular python on which you've built your application is extremely likely to still function and at worst can be compiled. Furthermore, python specifically allows for multiple concurrent python installations. Furthermore, by in large, python is forward compatible between major releases. So the hand waving you're doing is just that...not an issue in the least.

              It may surprising many people who think along the same li

              • Re: (Score:2)

                by tepples ( 727027 )

                In five or ten years from now, the python VM of the particular python on which you've built your application is extremely likely to still function and at worst can be compiled.

                But good luck finding a hosting provider that offers a particular version of Python without having to pay an order of magnitude more to rent your own dedicated server.

                • Yes, $10.00/month is horribly expensive and common and is becoming more and more common every day.

                  You do realize its trivially easy to find hosting which allows you to install your own languages?

                  Python does not require root access to install. Not to mention, python's virtualenv [python.org] makes installing, configuring, and carrying your custom python environment and dependencies to other hosts trivial.

                  • Yes, $10.00/month is horribly expensive and common and is becoming more and more common every day.

                    Dude, some of us live in a cardboard box. The $0.99 rent is bad enough. The bundled free internet package is kind of nice . . . although sometimes it would be nicer to go a bit faster than 110 baud.

                • With the likes of Linode if you can't afford a VPS then you're are total small timer and certainly not a corporation which means porting to 3x shouldn't be an issue.

            • Re: (Score:3)

              by amorsen ( 7485 )

              I write something in Java, I know it's gonna work in 5 years

              More like you write something in Java, and it breaks with equal probability in an update from 1.6.0.0 to 1.6.0.1 as in an update from 1.6 to 1.7... At least that is my experience as a user of Java Applets.

              Server-side this does not matter much because few people upgrade Java anyway.

            • Except for the fact the previously mentioned C# is increasingly growing in popularity as is Python. I'm sure corporations that think IE6 is still a good browser don't mind a language never growing but the rest of the world likes their languages to evolve and grow.

        • Re:Another great Python 3.x series release (Score:5, Insightful)

          by luis_a_espinal ( 1810296 ) on Monday February 21, 2011 @09:58AM (#35267768)

          This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.

          I'll admit I've never developed a programming language, but I have worked on large, long term libraries, and I think the same principle applies. All those stupid design decisions and approaches that are now obsolete and make no sense.. you have to make them still work anyway. You can spew lots of warnings.. but to me breaking backwards compatibility in a _programming language_ is sloppy and completely unacceptable.

          Well, you don't have to migrate to Python 3.x. There are a lot of Java 1.2 code out there that will never be migrated, code that sooner or later will not run as intended with new JVMs and JDKs. Code written in COBOL still runs and will never be re-writen (not in our lifetimes).

          If it works for you on the 2.x series, most likely it will work fine in years to come. Coming from a Java world, I can tell you I wish the JCP had done the same with many Java crap. Hashtables and vectors should have been deprecated long ago; the '+=' operator in Strings should also have been deprecated; we should have created a damned new collections library so that we could have true generics without type erasure; the JVM should have implemented support for tail recursion; and we should have gotten rid of this one-class-def-per-class-file non-sense.

          True, it would have broken a lot of stuff, but only for those that want/need to migrate - many do not. But it would have been a way to get things right and undo a lot of past design wrongs. At some point, it is time to cut backwards compatibility. For those who can't go to the 3.x series, they should simply stay with the 2.x series and work as usual.

          • Re: (Score:2)

            by Anrego ( 830717 ) *

            should have gotten rid of this one-class-def-per-class-file non-sense.

            I'm actually a fan of this! I do it in my c++ coding as well.

            If a class is specialized enough to only really be useful to one class.. it can be defined as part of that class, but I generally avoid that for all but the most trivial stuff (specialized action listeners that need to take parameters being my most common reason for this).

            • should have gotten rid of this one-class-def-per-class-file non-sense.

              I'm actually a fan of this! I do it in my c++ coding as well.

              If a class is specialized enough to only really be useful to one class.. it can be defined as part of that class, but I generally avoid that for all but the most trivial stuff (specialized action listeners that need to take parameters being my most common reason for this).

              I'm sorry but you don't seem to know what I'm talking about.

              I'm not talking about Java source code (where you can have multiple classes defined in one .java file). I'm talking about the output of the compiler, which generates one .class file (bytecode) per class definition, and the JVM inability to operate otherwise. This has serious implications at runtime when it comes to allocating permanent VM memory and can put the brakes on people designing programs with JVM-based functional languages.

              • I'm sorry, but I fail to see how the compiler separating the byte-code for a class into a separate file has a tremendous affect on memory. How is that any different than the compiler taking that class and appending it to another class file? All the files are located in what basically amounts to a zip file so whether the VM has to look at a different virtual file or a different byte location in that file, it makes no difference.

                I can't see how having the class in a separate file makes an ounce of differenc

          • Code written in COBOL still runs and will never be re-writen (not in our lifetimes).

            not true at all, I've re-architected major COBOL systems (and their ISAM / VSAM databases) several times in my career, to SQL DBMS with J2EE and scripting languages.

            • Code written in COBOL still runs and will never be re-writen (not in our lifetimes). not true at all, I've re-architected major COBOL systems (and their ISAM / VSAM databases) several times in my career, to SQL DBMS with J2EE and scripting languages.

              Reading comprehension dude. I didn't say all existing COBOL code, I simply said Code written in COBOL as in "the general case" or as in "on average" (which is the only way to properly interpret such a sentence.) Yes, you can make a living porting COBOL code to other platforms, yes, it does occur. And yes, it can still occur against the backdrop of the obscenely immense COBOL code base that won't be rewritten anytime soon (if ever.) Your statement - while true - does not contradict the later.

        • Well, it's free software. If enough people don't want to move to Python 3, they can always fork their own project from 2.7. GvR and his followers, however, have decided to focus their efforts on Python 3, leaving the Python 2 cruft behind, and I don't think they're going to change their minds at this point.

        • Re: (Score:3)

          by Sloppy ( 14984 )

          I feel the pain, but if they had called the language by a new name, wouldn't that nullify the objection? Ruby isn't compatible with Python 2.x libraries either, but no one flames it for that, any more than they blame Python 2 for not being able to run awk scripts. If you can't break compatibility, then nobody can do anything new.

          Think of Python3 as a new (though not particularly ground-breaking) language which happens to be very Python2-like, rather than as an update to Python. If you look at it that way

          • if they had called the language by a new name, wouldn't that nullify the objection?

            In fact it would; see my reply to maxume [slashdot.org].

            Think of Python3 as a new (though not particularly ground-breaking) language which happens to be very Python2-like

            And which has a name confusingly similar to that of Python 2. And which uses the same file name extension as Python 2. And which takes web hosting services that currently offer Python 2 far longer to adopt. Many of the same arguments were tossed around when someone proposed calling the successor to Visual Basic 6 by the name Visual Fred [google.com].

            • Re: (Score:2)

              by Korin43 ( 881732 )

              ... And which takes web hosting services that currently offer Python 2 far longer to adopt....

              Most components of Python-based websites still haven't been ported to Python3. It's not surprising that shared hosting providers don't offer something that doesn't exist.

            • Re:Confusingly similar name (Score:4, Insightful)

              by PCM2 ( 4486 ) on Monday February 21, 2011 @05:11PM (#35272500) Homepage

              And which has a name confusingly similar to that of Python 2. And which uses the same file name extension as Python 2. And which takes web hosting services that currently offer Python 2 far longer to adopt.

              Consider yourself lucky with Python, then. C code written for two entirely different machine architectures uses a similar (but inconsistent) syntax and the same file extensions; in fact, the same *.c files might not compile successfully using two different compilers on the same box. Really, you're holding Python to a standard that no other language has ever been able to meet.

        • Re: (Score:3)

          by costas ( 38724 )

          Why not? isn't a programming language a big library of sorts anyway? should you keep supporting every bad design decision for ever and ever?

          Python has been extremely conservative about both introducing and deprecating features (the __future__ import is genius). Python 3 had to stay within the rational side of the Perl-6 line, and I believe they pulled it off.

        • This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.

          The problem with endless back-porting is that it stagnates any âoerevolutionaryâ development of the language. There are certain âoemilestonesâ where it makes sense to completely walk away from the old ways of doing something and move on. At a certain point, back-porting makes everything âoehalf-bakedâ.

        • Imagine if when developing the jet engine, Whittle had to make it backwards compatible with the piston engine. You know - it still needed to use the same fuel, it still only had the same bearings specifications, same exhaust temperatures, couldn't use different lube oil, and so forth... Yes it's a pain but if you want to advance sometimes you have to toss something that has reached the end of it's life and take a large jump forwards. Python 2 will probably go for a lot longer, just like prop-engines do now

          • Physical manufacturing can't be compared fairly. Every widget created has a cost, which reduces the relative cost of designing a new type of widget (and gets amortized over time). With software, the cost of designing a new type of widget (porting software across OSes or language revisions) is pretty much the entire thing.

            Plus, your analogy is off. Comparing jet and piston engines is akin to comparing different programming languages, not different versions of a programming language. The Python folks dec

        • So consider Python 2.0 as a legacy language then, and Python 3.0 as a new one.

          It'd be nice if all library, language developers had super-human powers of future-prediction, but guess what... they don't. When designing a piece of software, there's only so far you can accurately predict potential future requirements and design to accommodate those. At some point your requirements change beyond the scope of what you were able to anticipate and you've got two choices:

          1) Hack the new features in - thereby dooming

          • 2) Refactor/redesign to reflect the new requirements and as much of the future you can predict from this new position. Maybe you can do this while keeping backwards compatability, and maybe you can't.

            If you can't keep backwards compatibility, then you're not actually refactoring. In the context of this discussion, the changes being discussed are most definitely not refactoring. Please don't dilute the term, or it'll have less power when we need to argue it to our managers.

          • So consider Python 2.0 as a legacy language then, and Python 3.0 as a new one.

            That'd be great if I could have both languages installed side-by-side on Windows, or on Ubuntu without having to compile from source, or on a shared hosting provider.

        • Re:Another great Python 3.x series release (Score:5, Insightful)

          by dkleinsc ( 563838 ) on Monday February 21, 2011 @11:53AM (#35268822) Homepage

          Counterargument A: The stupid design decisions and approaches that are now obsolete and make no sense should be forced out of code. Otherwise, the Bad and Wrong version persists a lot longer than it should: some mediocre developer will Google how to solve a Python problem, get something that explains the Bad and Wrong version, puts it into their code, may get a bunch of deprecation warnings, but figures "hey it works, good enough". And if you need an example of how badly out of hand that can get, look at PHP, which still has to support really really stupid things from PHP2 or so because of backwards-compatability, and thus leaving behind a legacy of horrific PHP code.

          Counterargument B: Ensuring backwards-compatibility always forever and ever ensures that the language complexity can only grow, never shrink. And thus you grow and grow and grow until eventually the language cannot even be completely defined using BNF or anything similar. Case in point: C++.

        • Re: (Score:2)

          by sjames ( 1099 )

          If you like, consider it 2 languages, Python2.x and Python3.x that bear a remarkable resemblance to each other. Python has bent over backwards to avoid problems with the transition. 3.0 and 3.1 features got backported and 2.7 is going to be maintained long term while development continues in 3.x only. It's not like all your Python apps will break tomorrow when you are forced to remove your 2.7 system and install 3.2. I imagine it will be quite common to have 2.7 and 3.x installed together for a while to com

      • Re: (Score:2)

        by arth1 ( 260657 )

        Unfortunately, converting isn't always an option, like with packages that auto-update or write python code, not to mention those that depend on a 1:1 character/string length (i.e. assumes iso-8859-1 or similar).
        So the reality is that if you want to use 3.x, you'll quite likely have a system with both 2.x and 3.x, with python defaulting to 2.x

        I.e. much the same situation as with java, where you quickly end up with a whole boatload of incompatible virtual machines, one for each app you run.

        And this is one of

      • Unnecessary complexity (Score:2, Interesting)

        by mangu ( 126918 )

        I don't understand how this Py3k praising always gets such good moderation on /.

        Python 3 has left the original focus of the language as something simple and easy to use. All the changes are towards a MORE COMPLEX language, I see no change that makes it simpler to use, no change that requires less code than the former version.

        Py3k is moving in the direction of Java, where nothing can be done without typing a hundred lines of code. An example from the Python documentation:

        17.1.3.1. Replacing /bin/sh shell bac

        • Re: (Score:2)

          by maxume ( 22995 )

          Removing backtick support actually makes the language simpler.

          (I realize that it does make simple shell access more complicated, by requiring that it be done with a library function (but removing syntax still simplifies the language))

        • Re:Unnecessary complexity (Score:5, Informative)

          by nneonneo ( 911150 ) <spam_hole@s[ ].ca ['haw' in gap]> on Monday February 21, 2011 @11:10AM (#35268444) Homepage

          Python never had shell backquotes. The code snippet is highlighting one way that shell backquotes from other languages can be handled. (The "backquote" operator in Python 2.x is equivalent to "repr", e.g. `3+4` yields '7'; it is now gone in Py3K for obvious reasons).

          In Python 2.7 and 3.1, there's now a convenience function for capturing program output:

          subprocess.check_output('ls -l')

          I doubt your claim that Py3K has made things more complicated. If anything, it has made things simpler: less language "burrs" (e.g. / now does float division, eliminating the need to stick float() on one argument or use weird constructs like 1./3), a cleaner standard library ("io" is a great idea), and proper Unicode/8-bit distinction.

          • If anything, it has made things simpler: less language "burrs" (e.g. / now does float division...)

            That particular "burr" I think is something that divides people. While it does make certain generic functions simpler, it's arguably less intuitive for some large user-bases:

            • whole-number math (i.e. kids and certain branches of mathematics): 5/4 == 1 remainder 1, or 1 + 1/4.
            • programmers who have ever used integers before: 5/4 == 1 due to truncation. Also—and this is very important in a culture of ab

          • Re: (Score:2)

            by HiThere ( 15173 )

            The "io" class is, I think, a good idea. (I'm less certain about it than you are.) But it definitely makes using the language more complicated. Some of this is because the documentation needs more examples of usage, but not entirely. It actually *is* more complicated to use. It's still probably a good idea, and it's a lot better than the mess Java made of *its* IO systems.

            The thing is, actual use of features tends to be full of corner cases where the documentation doesn't clearly specify what happens.

        • Re: (Score:2, Informative)

          by GooberToo ( 74388 )

          I don't understand how this Py3k praising always gets such good moderation on /.

          Well, that's because you just don't understand. Period.

          Python 3 has left the original focus of the language as something simple and easy to use. All the changes are towards a MORE COMPLEX language, I see no change that makes it simpler to use, no change that requires less code than the former version.

          That's a mouth full but only shows you not only don't understand, but haven't bothered to even look. In what way are things more complex? You mean by adding more language features with easier syntax (example, comprehensions), things are harder? You mean by creating more explicit and less confusing exception handling, things are harder? You mean by adding additional features to support threading concurrently things are harder? You mean by improving threa

        • Re: (Score:2)

          by mickwd ( 196449 )

          I don't understand how this Py3k praising always gets such good moderation on /.

          Perhaps what you don't understand is how anyone can have a point of view other than your own.

          I cannot see how would anyone call this an "improvement"... Oh, sure, it gives me more options, more control...

          And still you cannot see?

        • Re: (Score:2)

          by beej ( 82035 )

          I see no change that makes it simpler to use, no change that requires less code than the former version.

          "I mean, if you've seen one change, you've seen 'em all."

          "And have you seen them all?"

          "Well, I've seen one. Well, a little one... a picture of a... I've heard about them."

          Unicode and binary data handling. That's enough for me, right there. The new command line parsing stuff is more concise than getopt. And it parses JSON, too.

          Not everyone is going to like every change, but declaring you've seen no change for the better out of the huge number of changes just means you haven't looked enough.

    • Re: (Score:2)

      by maxume ( 22995 )

      The goal of Python 3 was never to have everyone using it in 2012, it was to have a nicer Python language available at some point a little further into the future. For things like the str->unicode conversion, a big break is one of the better ways to transition.

      And lots of people are unhappy that things didn't get painted their favorite color, but the process used, where people willing to do the work to make changes were the ones that made changes, was fairly democratic.

    • That no one will use because there is no compelling reason to port all that cool stuff developed for the 2.x series.

      Yeah, because everything that needed to be developed has already been done so under the 2.x series. No one will ever need or think to develop something new on the 3.x series. That's why all we have is COBOL because nothing new has ever been needed after all those apps were written with it, oh wait, never mind.

    • Re: (Score:3)

      by jabjoe ( 1042100 )
      EXACTLY. If the Python devs leave 2.x too long and keep saying 3.x only, they will find someone will just fork 2.x and continue it. In free software you only get to make the rules while the community thinks they are good, or it's "fork you!" and the community goes elsewhere.

      To me, all the supporting both 2.x and 3.x looks really messy, and why support 3.x if no one else does? Python 3 doesn't seam to be making any progress is taking over and I think it is because it's 2.x with the critical mass. In thing

      • EXACTLY. If the Python devs leave 2.x too long and keep saying 3.x only, they will find someone will just fork 2.x and continue it. In free software you only get to make the rules while the community thinks they are good, or it's "fork you!" and the community goes elsewhere.

        This was the arguement against KDE 4. It took some time, but I am glad that the KDE group went in the direction they did.

        Also, if python 2.x is their past, I doubt they care if it gets forked. If it breaks compatibly with the version they finished, then it is self defeating. If it doesn't, then it doesn't affect them other than someone else will be responsible for any bug/security fixes

      • Re:Another great Python 3.x series release (Score:4, Informative)

        by tdelaney ( 458893 ) on Monday February 21, 2011 @03:24PM (#35271376)

        Guido has stated quite publically that anyone is welcome to fork any version of Python - this exact topic has been discussed many times on python-dev (the mailing list for development of Python). Of course, it's up to them to maintain and popularise the fork.

        What they don't get to do is call it Python. "Python" is a trademark of the Python Software Foundation [python.org] when the term is used to refer to a programming language.

        The fork could be called a "Python-like" language, or even claim to be "Python-compatible"*.

        * for some level of "compatible".

      • Re: (Score:2)

        by HiThere ( 15173 )

        Why would a fork of Python 2.x be expected to be more compatible with what you want than Python3? If you aren't satisfied by Python2.6 or Python2.7, then you obviously want some different features. And what makes you believe that whoever forks it will want the same features with the same syntax that you do?

        For me the primary argument that Python3 is the way to go is unicode. Using unicode strings in Python2.x is a pain. It can be done, and I'm currently doing it, because when I started this project the

  • News for nerds? (Score:5, Funny)

    by Anonymous Coward on Monday February 21, 2011 @09:11AM (#35267408)
    Come on, guys. How does this help us keep up to date on political events, popular music, or funny videos?

    • #!/usr/bin/python3
      import urllib2

      stuff = ['news.google.com', 'grooveshark.com', 'youtube.com/failblog']

      for i in stuff:
          print urllib2.urlopen(i).read()

      Thats how!

      • Re:News for nerds? (Score:5, Funny)

        by blai ( 1380673 ) on Monday February 21, 2011 @10:03AM (#35267830)
        print requires brackets now.

      • Re:News for nerds? (Score:4, Funny)

        by GooberToo ( 74388 ) on Monday February 21, 2011 @01:23PM (#35269946)

        # This works with any python installation rather than only the system installation.
        # Using explicit path to system's python install is bad practice. Requiring a source change to run your application with a different VM is silly. Now we need only change our path.
        #!/usr/bin/env python3
        import urllib

        stuff = ['news.google.com', 'grooveshark.com', 'youtube.com/failblog']

        for i in stuff:
                print( urllib.urlopen(i).read() )

        • if you wanna be a smart ass, then don't write it wrong!

          the file must start with the interpreter - otherwise it won't even run.

          #!/usr/bin/env python3
          # This works with any python installation rather than only the system installation.
          # Using explicit path to system's python install is bad practice. Requiring a source change to run your application with a different VM is silly. Now we need only change our path.
          #/!\ if your OS doesn't have python as system package, i don't want you to use my script anyway. I wan

  • Is the GIL removed from the interpreter (Score:3, Informative)

    by JonySuede ( 1908576 ) on Monday February 21, 2011 @09:16AM (#35267456) Journal

    Is the GIL [mirocommunity.org] removed from the interpreter ?

    • Re:Is the GIL removed from the interpreter (Score:4, Informative)

      by greg1104 ( 461138 ) <gsmith@gregsmith.com> on Monday February 21, 2011 @10:43AM (#35268204) Homepage

      Yes, it would be great if an update to this were covered in the article, like if they put notes on changes to the GIL right here [python.org] or something.

      • thank you

  • Goodbye, Python 2 (Score:3, Interesting)

    by ArcRiley ( 737114 ) <arcriley@gmail.com> on Monday February 21, 2011 @09:30AM (#35267572)

    I don't know of a major Python library that isn't upgrading to Py3 - and this release marks the tipping point where we wave goodbye to the aging 2.x codebase.

    PEP-3003 [python.org], the moratorium to changes to the language to allow alternative Python implementations to catch up, only applies up to the 3.2 series so we're going to continue moving forward from here. Nobody's forcing Python 2 users to upgrade their code, but there's many advantages and ever decreases hurdles to doing so.

    Don't fear change, this change is good and necessary for the advancement of the language.

    • Panda 3d?

      • I don't know its status, but at best panda is a niche package.

        Besides, as things finally reach critical mass with the python 3.x series, as is just now starting to happen, its momentum will naturally pick up other packages along the way. The feature set in the 3.x series is already become very attractive, over that of the 2.x series. Its gravitational pull from new features is only going to build over time.

      • PIL is working on Python 3; "The current free version is PIL 1.1.7. This release supports Python 1.5.2 and newer, including 2.5 and 2.6. A version for 3.X will be released later" (source [pythonware.com]). So is Django, Turbogears, wxpython, pygtk, etc. You can vote [python.org] on which major 3rd party packages you'd like to see ported.

        PyQT, CherryPy, Genshi, and many others [python.org] are already ported to Python 3.

    • They also recently created a PEP which formalizes gateway interfaces for byte and unicode support which means all of the larger python web frameworks are finally lifting anchor and heading toward 3.x waters.

      In the next few years, we'll definitely see a huge uptake in the 3.x series.

      Really the question is, how much with pypy be able to absorb from the current cpython 2.x community and when will it take on a 3.x persona.

    • Re:Goodbye, Python 2 - NOT (Score:4, Insightful)

      by Animats ( 122034 ) on Monday February 21, 2011 @01:01PM (#35269636) Homepage

      I don't know of a major Python library that isn't upgrading to Py3 - and this release marks the tipping point where we wave goodbye to the aging 2.x codebase.

      Ah, denial. Some major modules that aren't making the transition:

      • BeautifulSoup (HTML/XML parser - replaced by HTML5parser, which is much bigger and slower and has a completely different output tree.)
      • MySQLdb (MySQL database interface. The developer says it's too hard to convert it to Python 3.)
      • M2Crypto (interface to OpenSSL - replaced by new, incompatible SSL module.)
      • SGMLparser (Used by some other modules)
      • FeedParser (Reads RSS feeds. No replacement.)

      And those are just ones I happen to have used.

      Because the Python community is so tiny, there are major modules that are maintained by only one person. In many cases, they've moved on to other things, and no one is maintaining the modules. The major changes required to move to Python 3.x are non-trivial and aren't being done, because someone would have to take responsibility for a big module they didn't write to do the conversion. In some cases, there are newer, completely different modules with different APIs that perform the old functions. So end users have to do a major rewrite on production programs just to stay in the same place. It's a huge transition. Guido has this smoke-and-mirrors pitch claiming that it's "done". That's because the Python organization, such as it is, disclaims all responsibility for getting modules ported. So it's not his problem that it sucks.

      None of the non-CPython implementations are making the transition. Not IronPython (abandoned by Microsoft). Not Shed Skin (only one developer). Not PyPy (defunded by the European Union). Not even Google's own Unladen Swallow [google.com] is moving to Python 2.6, (Google seems to have abandoned Unladen Swallow after discovering that Guido's insistence on excessively dynamic features meant a JIT compiler didn't speed it up much.) The transition to Python 3 has thus killed all other Python projects.

      CPython is a naive interpreter, roughly 60x slower than C. It's been stuck at that speed for a decade. And now, that's all we have left.

      If you're using Python for anything important, start working on your exit strategy.

      • Re:Goodbye, Python 2 - NOT (Score:4, Informative)

        by GooberToo ( 74388 ) on Monday February 21, 2011 @02:20PM (#35270638)

        There's a little bit of revisionist history going on in your post but I don't get the impression that's by intent.

        Ah, denial. Some major modules that aren't making the transition:

        That was a silly thing for him to say. Clearly some modules are not actively being ported. That, however, doesn't mean they won't or can't.

        The major changes required to move to Python 3.x are non-trivial and aren't being done

        Very much over stating the difficulty. There has already been a number of porting sprints. In a number of cases, rather large frameworks have been ported over a weekend. By in large, the porting effort actually is extremely trivial and frequently, the automated tools can complete 90-95% of the port by themselves. Really, the ports which tend to be problematic are the ones with large, legacy code bases. These are non-trivial not because of their size, but because of the porting effort in of themselves is a function of line count.

        In some cases, there are newer, completely different modules with different APIs that perform the old functions. So end users have to do a major rewrite on production programs just to stay in the same place.

        Could you be more specific. I'm actually drawing a blank here. Its true some functions/classes have been moved to other packages. Most of the time its as simple as changing an import or a namespace prefix associated with a function call. Again, most of the tedium is addressed by means of the automated porting tools. And if you do have examples, please offer up why such an example affects such a wide breath of existing code its more than a corner case.

        It's a huge transition.

        Again, you're way overstating the problem.

        Guido has this smoke-and-mirrors pitch claiming that it's "done". That's because the Python organization, such as it is, disclaims all responsibility for getting modules ported. So it's not his problem that it sucks.

        Trollish and red herring in nature. Not really applicable to the discussion at hand. So now Guido is responsible for all python code which has ever been written. Such a statement is silliness at best.

        None of the non-CPython implementations are making the transition.

        This has what to do with anything? And how many dozens of people really care?

        Not IronPython (abandoned by Microsoft).

        So now a port of python that no one used is a significant weight preventing the adoption of the latest python release? Completely rediculas. If anything, it further underscores the stupidity of IronPython and MS' mind-share-gimick-marketing rather than serving as a detracting for python migration. Bluntly, I'm sure IronPython's three users are really upset that they made such woefully bad decisions to adopt IronPython (contrary to the rest of the world's warnings and MS' very long associated history).

        Not Shed Skin (only one developer).

        That's because he's one developer and doesn't have the man power. Its not that he won't, rather, its that he is simply one man. Furthermore, Shed Skin is a niche product. Its neat and all, but it has a long way to go before, frankly, anyone other than that one developer really gives a crap about it. Don't get me wrong, its a cool tool, but I won't use it for production. Hell, most python developers don't even know about it. And when they do, they tend to think of it as an experimental toy. Seemingly, the author sees it this way too. So again, not a detractor for Python 3.x in the least. You're being silly.

        Not even Google's own Unladen Swallow is moving to Python 2.6, (Google seems to have abandoned Unladen Swallow after discovering that Guido's insistence on excessively dynamic features meant a JIT compiler didn't speed it up much.)

        Completely wrong and extremely trollish in nature. Unladen Swal

        • Re: (Score:2)

          by Animats ( 122034 )

          Completely wrong and extremely trollish in nature. Unladen Swallow (US) is a dead project because other projects have already exceeded US' goals.

          Here's what the developers of Unladen Swallow had to say: [google.com]:

          Hi Arek, On Mon, Nov 8, 2010 at 1:10 AM, Arek StefaÅski wrote:
          > Hey, I thought Unladen Swallow is dead.
          > Sure seems close to this.
          > It's really cool project, why is it so 'abandoned' right now? :
          Jeffrey and I have been pulled on to other projects of higher importance to Google. Unfortunately, no-one from the Python open-source community has been interested in picking up the merger work, and since none of the original team is still full-time on the project, it's moving very slowly. Finishing up the merger into the py3k-jit branch is a high priority for me this quarter, but what happens then is an open question.

          Collin Winter

          Doesn't sound like "because other projects have exceeded US goals", does it?

  • Anti-Gravity (Score:3, Funny)

    by Rik Sweeney ( 471717 ) on Monday February 21, 2011 @09:32AM (#35267582) Homepage

    Have they added Anti-Gravity [xkcd.com] yet?

  • How can a stable ABI be described as "new?" Hey guys, it's stable! And it has been stable for 24 hours!

    In other news, I quit smoking! I haven't had one since last night right before I went to bed.

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close