Slashdot Mirror

← Back to Stories (view on slashdot.org)

Python 3.4 Released

Posted by Soulskill on from the onward-and-upward dept.

New submitter gadfium writes: "Python 3.4 has been released. It adds new library features, bug fixes, and security improvements. It includes: at standardized implementation of enumeration types, a statistics module, improvements to object finalization, a more secure and interchangeable hash algorithm for strings and binary data, asynchronous I/O support, and an installer for the pip package manager."

4 of 196 comments (clear)

  1. and... by Anonymous Coward · · Score: 5, Insightful

    And everyone will keep using 2.6/2.7, the windows XP of python.

    1. Re: and... by Anonymous Coward · · Score: 5, Informative

      This is why there's a bytes type.

      If what you have is not text, don't use the text type.

    2. Re: and... by Anonymous Coward · · Score: 5, Informative

      The inconsistencies are fully within Python 2. My experience is closer to full-scale horror when having to consider different encodings in Python 2, and since I am from a country that actually needs these "bells and whistles" regarding encoding for regular I/O on a regular basis, I have met these issues many times. Using chains of codecs to read and write files, having to intercept exceptions and .encode() .decode() in differing combinations to be able to avoid Python 2 "double-crashing" when reporting an exception, deep level hacking to reinitialize sys.stdout before output on certain machines, etc.

      In Python 3, it does not "just work", but that is because character encoding is never a "just works" problem, and languages that say it is fail miserably in this regard as soon as it meets real world international encodings. Python 3 defines the problem correctly, and solves it natively in the best way I can imagine, by always being aware of the problem. No more prepending the u qualifier to every single string that might or might not be output (or combined with any other string that might or might not be output). Python 3 solves it correctly, by acknowledging character encoding as something that is actually an issue, and it does not make the silly assumption that ASCII is the way of the world. This assumption has been silly for at least 40 years, but many products were developed in ASCII centric regions, or at least in regions where you seldom saw more than one encoding, and never fully addressed the problem.

      The Python 3 standard library does strings right , and should get credit for it. Instead it gets flac from programmers who do not like that it does not inherit the quirks from Python 2 that we have become accustomed to (and are still miles better than in many other languages; PHP and unicode, anyone?).

      Heck, the number one reason that I have converted as many projects as I can to Python 3 is because of the blocks of encoding centered Python 2 code I can just throw out the window, and ease future maintenance. There are still some big module holdouts, but that was a much larger problem in ~2010. Today, the ones I miss in Python 3 are e.g. WXPython (where work is ongoing in the Phoenix project) and MySQLdb (the MySQL connection alternatives for Python 3 are outright silly -- either non-functional or non-documented).

      There are several introductory programming courses I know of that focuses on Python, and they all use Python 3 by default. I am sincerely looking forward to the day when Python 3 is the natural order.

      It takes a lot of motivation to change language structures from Python 2, and those working on the drafts are certainly top-class in their fields, so if one finds any design changes weird, the first instinct should be to read up on the rationales for the decisions. I have yet to encounter a change that seems "silly" or unnecessary after reading about the process.

      Also, for the early adopters, not that Python 3.3 (och 3.4, as this article is about) is not 3.0 or 3.1. There is a lot of things that have been fixed along the way.

  2. Re:And it still has the GIL by steveha · · Score: 5, Insightful

    You make it sound as if it were no big deal to remove the GIL. It has been tried, and Python got 2x slower, so that attempt was abandoned. Python 3.2 gained a different implementation of the GIL, and that fixed some problems, but other problems still occur.

    The GIL is Python's hardest problem.

    https://www.jeffknupp.com/blog/2012/03/31/pythons-hardest-problem/

    https://www.jeffknupp.com/blog/2013/06/30/pythons-hardest-problem-revisited/

    As noted in the above referenced blog, you can use Jython or IronPython to avoid the GIL; PyPy will be using Software Transactional Memory to avoid the GIL; and you can use the multiprocessing module to use multiple cores without GIL problems. You do have options other than just using CPython.

    If removing the GIL was as easy as you seem to think, it would be gone now, at least in a fork of CPython. Yet still it remains.

    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely