Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Python Programming

Python 3.3.0 Released 131

Posted by Soulskill from the onward-and-upward dept.
An anonymous reader writes "After just over a month of release candidates, the final version of Python 3.3 launched today. This version includes new syntax, including the yield from expression for generator delegation; new library modules, including fault handler (for debugging crashes), ipaddress, and lzma (for data compression using the XZ/LZMA algorithm); a reworked OS and I/O exception hierarchy; the venv module for programmatic access to Python virtual environments; and a host of API changes. The full list of features and the change log are both available."
This discussion has been archived. No new comments can be posted.

Python 3.3.0 Released More

Python 3.3.0 Released

Comments Filter:

  • Wait! (Score:1)

    by XphX ( 2741853 )
    And...But...I just downloaded 3.2 -_-

  • It's no Perl6 (Score:1)

    by Anonymous Coward

    I'm waiting for that

  • While I like some of the changes in python3, breaking compatibility with python2 was a huge fail.

    From python3 release notes (dated December 3rd, 2008):

    '''Python 3.0 (a.k.a. "Python 3000" or "Py3k") is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard
    • True but speed on conversion for some big projects is picking up. They will have to move and there will always be packages that aren't really maintained that will sit there and not get updated but those packages would have eventually broke eventually anyway. But luckily when it's just down to a smaller percentage of people refusing to switch, they won't cause an inconvenience on the rest of us.

      • Re: (Score:1)

        by Anonymous Coward

        I tend to agree. Most *libraries* that are still actively maintained either already support Python 3, have Python 3 ports in the works, or have contributed patches to support Python 3. Most abandoned projects will probably never get ported, but that's just life in the FLOSS lane. Newer, better, more compatible alternatives will become available. Most new projects usually include Python 2 and Python 3 support right from the start. It's not difficult.

        Of course, the higher up the food chain you go, the fe

    • One reason why Python 3 hasn't taken off is that it didn't adopt .py3 as a file name suffix for Python 3 programs. This makes side-by-side installation of Python 2 and Python 3 much more difficult. Does Python 3.3 yet have a feature where I can have both Python 2 and Python 3 installed on a PC running Windows, and double-clicking a .py file in Windows Explorer runs the correct interpreter version? Until that's fixed, with a .py handler that starts Python 2 or Python 3 depending on future statements or the s
      • That's what shebangs are for - #!/usr/bin/env python2 means 2.x, python3 means 3.x - don't blame Python because Windows doesn't follow convention. That said, there is a PEP that was accepted for a windows launcher that would do the right thing, but I don't know what the state of that is.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          The launcher is added with 3.3 and suppose you can install it separately too.
          http://docs.python.org/dev/using/windows.html#launcher

          Tried and had no problems with python2.7 and python3.3 installed

          • Anonymous Coward wrote:

            The launcher [python.org] is added with 3.3

            Thank you. Side-by-side on Windows was broken in 3.0, 3.1, and 3.2, but now that it appears fixed, one more obstacle to adoption of Python 3.3 is out of the way.

      • Re:Because .py3 wasn't used (Score:4, Informative)

        by Waffle Iron ( 339739 ) on Saturday September 29, 2012 @01:36PM (#41500435)

        One reason why Python 3 hasn't taken off is that it didn't adopt .py3 as a file name suffix for Python 3 programs.

        A lot of the Python programs I've written don't have any extension on the file name. They're intended to be commands in the system. The language they're written in is an unimportant implementation detail (and might change one day). There's usually no need to make the implementation language user-visible.

        • There's usually no need to make the implementation language user-visible.

          I agree in some cases, such as on a Linux or *BSD server where shebangs or rewriting or type-maps or MultiViews can safely keep the implementation language out of the URL space. But on the Windows desktop, Microsoft tried this with "Hide extensions for known file types", and it led to all sorts of trojans where the user didn't realize that what the user thought was a document was actually an executable.

      • What's wrong with .sh for your Python programs? Or no extension at all?

        Interpreters in Unix are specified in the file, not by file nomenclature. All my Python2 software starts with:

        #!/usr/bin/env python2

        If I want to know what a program is, I of course use:
        file /usr/local/bin/program
        program: a python2 script text executable

        • What's wrong with .sh for your Python programs?

          The fact that I'd have to replace Windows Explorer on end users' Windows PCs with a UNIX style shell. This was a problem until Python 3.3, which associates .py files with a limited shebang interpreter as AC mentioned [slashdot.org].

    • Re: (Score:1)

      by Anonymous Coward

      Python 2.7.3 is the new IE6

      Except that IE 6 is an abomination to all mankind, while python 2.7.3 is not.

    • Breaking compatability was the best idea ever. If compatability hadn't been broken, the language couldn't fix the mistakes that were there. Unlike so many languages, Python is truly designed, not just made. There were mistakes and those have been fixed for 3.x, and that's what every language should strive to do. Look at JavaScript if you want to see the example of a language that refuses to fix it's mistakes - a broken mess that requires a mass of libraries to work with in a semi-sane manner.
      • What mistakes are you referring to? What was so broken in Python 2 that required a completely incompatible Python 3 as a fix?

        • Re: (Score:1)

          by Anonymous Coward

          What mistakes are you referring to? What was so broken in Python 2 that required a completely incompatible Python 3 as a fix?

          Changes in Python 3 [python.org]

          • Some changes to clean up the syntax parsing by removing odd or obsolete areas such as the overly-clever 'print' syntax which required special parsing rules
          • Old-style classes duplicated the new-style classes
          • Changing many parts of the language to return iterators or generators rather than lists
          • Well defined Unicode handling as standard throughout the language allows a proper differentiation between bytes and strings

          The first three don't have too much of an impact to anyone who does not writ

    • Don't let the mods fool you. Breaking compatibility was intended from the beginning. You are thinking it can be done right ala Windows, without realizing that not breaking backwards compatibility was the huge fail. Also, if you knew about Python, you would know that backwards compatibility across minor revisions is not guaranteed either. You can't make progress and fail to make progress at the same time.

    • Re: (Score:2)

      by DThorne ( 21879 )

      In the VFX community, you pretty much stray from 2.6 at your peril, and certainly 3.x is a no-fly option if you want to stay 'current' with the latest apps. It's incredibly frustrating, since the previous 'standard', if you could call it that, was TCL, and python is better on so many levels...but this has tainted it mightily.

    • Re: (Score:2)

      by Eil ( 82413 )

      While I like some of the changes in python3, breaking compatibility with python2 was a huge fail. [...] Python 2.7.3 is the new IE6.

      How very hipster of you.

      But, you're simply wrong. If you had bothered to do even the slightest bit of reading [python.org], you'd know full well that the Python creators never intended for Python 3 to replace 2 overnight. The break in compatibility was done deliberately, and with a great deal of thought. There are a number of things fundamentally wrong with Python 2 that can't be fixed with

      • Re: (Score:3)

        by csumpi ( 2258986 )
        Thanks for calling me a hipster, I take it as a compliment.

        While python2 and python3 might have been intended to be installed alongside, that just didn't work out and created a huge mess. By the time your script would know that it's been loaded with the wrong version of python (as for a script that starts with #!/usr/bin/env python it's not possible to know what it will get), it's too late, because python crashed it for syntax errors.

        Python is an interpreted language. There's no reason why compatibility

  • if any of y'all want to have some fun then take a stab at converting MakeHuman to Python 3.* (please note if you can get it to run contact the Project Managers)

    Of course if you want to play with an Open Source version of Poser you can also have fun.

  • Weak third-party library support (Score:5, Interesting)

    by Animats ( 122034 ) on Saturday September 29, 2012 @12:31PM (#41499825) Homepage

    The trouble with Python 3 is that nobody took responsibility for converting the third-party libraries. Many major libraries became abandonware in that transition. Rather than converting the old ones, in some cases, new incompatible libraries were developed. So not only do you have to convert your code from Python 2 to 3 (for which there is a tool to help), you have to change your code to use new libraries. Python doesn't have enough market share that major projects like MySQL and OpenSSL maintain the Python bindings for their project. At one point, the Python binding for OpenSSL was maintained by a World of Warcraft guild.

    Perl has CPAN, which actually hosts library source and has some Q/A functions. Python just has PyPi (formerly "Cheese Shop"), which is just a directory of links.

    This is Python's real problem. Python's Little Tin God For Life doesn't want the headaches of managing library maintenance. But he's not willing to let go and turn control over to an organization that can manage the grunt work of getting all the parts to work together. That's also why there is no Python ISO standard, and why none of the implementations other than CPython support 3.x.

    • I sincerely doubt Python 3 would ever have happened if there was an organization taking control, especially not when standards got involved. Breaking changes? That simply won't do for the enterprise. Python 3 is a massive improvement for a good reason, and the Python ecosystem works well. No, the Python 3 change hasn't happened overnight, but it's getting there - until it is there completely, you can just use 2.7.2 - a lot of the changes have been backported anywhere, where non-breaking.

    • Re: (Score:1)

      by Anonymous Coward

      This just isn't how volunteer driven, open source projects work. The core Python development community, along with a vast number of really fantastic contributors, does take responsibility for the core set of libraries in the standard library. The universe of third party Python code is so vast, there's no way any central organization could be responsible for porting it.

      I know Python 3 will be an unqualified success because I can see all the amazing project leaders who are porting their code to Python 3, or

    • Re: (Score:1)

      by robi5 ( 1261542 )

      Correct, since the libraries are either-or and 3.whatever was spottily supported the last time around (12 months ago), there are effectively two languages, Python2 (you need for those libraries) and Python3 (you'd rather use). Python's attractiveness diminished so much so that neither of these two languages were chosen.

    • Re: (Score:3)

      by Eil ( 82413 )

      The trouble with Python 3 is that nobody took responsibility for converting the third-party libraries. Many major libraries became abandonware in that transition.

      This is totally non-sensical. Those libraries would have become abandonware without the transition, as their authors had ceased to maintain them at any rate. It's good that others have written replacements. That's how the open source world functions.

      • Re: (Score:2)

        by jgrahn ( 181062 )

        The trouble with Python 3 is that nobody took responsibility for converting the third-party libraries. Many major libraries became abandonware in that transition.

        This is totally non-sensical. Those libraries would have become abandonware without the transition, as their authors had ceased to maintain them at any rate.

        I doubt that's what happened in most cases. Seems more likely that the authors are like me: they're in the Python 2.x world, run computers with Python 2.x as the default version, and see no compelling reason to migrate, especially if it would mean maintaining two branches of their library.

  • One other new feature (Score:5, Informative)

    by shutdown -p now ( 807394 ) on Saturday September 29, 2012 @06:06PM (#41502219) Journal

    It's a part of PEP 380, which is mostly about "yield from", but this little gem actually matters elsewhere. You can now return values from iterators. I.e.:

    def foo():
      yield 1
      yield 2
      return 3

    Since return from an iterator just raises StopIteration exception, they've added a field to propagate the value. Previously you could only use the no-argument return.

    Why this matters is because it gives you the final bit needed to provide full syntactic sugar to write asynchronous functions (task-based, chained callback model - think Node.js, or Twisted in Python land) as if they were synchronous, except that you use "yield" at the points where you want to cooperatively yield control. Of course yield is the bigger part of it anyway, and it was there before, but you had to use some magic function call to implement final return. Now it really looks exactly like a synchronous function, except for "yield".

  • There sure are a lot of posts here declaring what various people think "went wrong" with python 3. I find it pretty funny that each post describes a different perceived problem, yet reveals a similarly self-absorbed view, and in many cases a presumption that the 2-to-3 transition should have been universally complete by now. Folks, consider this: A project might not actually be a failure just because it's different from whatever you're used to.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close