Become a fan of Slashdot on Facebook


Forgot your password?
Python Programming

Python 3.4 Released 196

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."
This discussion has been archived. No new comments can be posted.

Python 3.4 Released

Comments Filter:
  • and... (Score:5, Insightful)

    by Anonymous Coward on Tuesday March 18, 2014 @11:16PM (#46521627)

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

  • by halfdan the black ( 638018 ) on Tuesday March 18, 2014 @11:41PM (#46521767)
    Yup, Global Interpreter Lock so Python is still fundamentally single threaded -- only a single thread can be executing any python code at any given instance.

    Its 2014 and we still can't have a multi-threaded python, this is ridiculous.

    If you read Guido's criteria for getting rid of the GIL, he lists so many things that are specific to the current single threaded system (which is evidently perfect) that the only solution that meets his criteria is the current system.

    I guess the only solution is to either live with single threaded system or fork it.
  • by steveha ( 103154 ) on Wednesday March 19, 2014 @12:12AM (#46521879) Homepage

    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. [] []

    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.

  • Re: and... (Score:5, Insightful)

    by dmbasso ( 1052166 ) on Wednesday March 19, 2014 @12:26AM (#46521929)

    There are plenty of good reasons to use Python 3, it is way more elegant and consistent. The way text and binary data is dealt with is incomparably better. I doubt that anyone who ever had done any serious coding in Python 2 escaped from the mindfuckery of mixing unicode and ascii.

    The problem for a wider acceptance continues to be the libraries... for instance, Twisted. It is good that there is an async module in the standard library now, but too bad that my code already relies heavily on Twisted.

    And about the GIL: if you are complaining about it, you most probably are not using the right language for the job.

  • by Anonymous Coward on Wednesday March 19, 2014 @01:23AM (#46522141)

    it shouldn't have been a surprise that it would spell doom for Python to fork it into two incompatible branches for a couple of "it would be nice" type features.


    The Python community, overall, approves of Python 3.x. The major breakages have to do with Unicode, but that's because Python 3.x does it right and Python 2.x didn't.

    If you don't think Unicode matters, my guess is you are an English-speaking American. Others disagree.

    There are efforts underway to port the major Python projects to support 3.x. SciPy will be the big one... Django already has support for Python 3.x.

    Perl6 never went anywhere, Python 3.x is in wide use.

  • Re: and... (Score:4, Insightful)

    by mypalmike ( 454265 ) on Wednesday March 19, 2014 @10:46AM (#46524169) Homepage

    > Unless you're a framework author, chances are you'll have to care very little about mucking with bytes.

    Right, because none of us write code that interacts with other code or systems that use bytes.

    Like C libraries.
    Or binary files.
    Or network protocols.

  • Re:Ubuntu Install? (Score:4, Insightful)

    by wjcofkc ( 964165 ) on Wednesday March 19, 2014 @11:49AM (#46524689)
    If someone is looking to install Python 3.4 the day it is released, they are not an average office worker. If someone is above average enough as a user to want\need this, they may as well have the expertise that goes with it. What exactly are you expecting them to be doing with it? Fully upgrading a 2.x system to 3.x will only break things - clearly nerdy goals are at hand. Therefor nerdier instruction in required. Plus there is no other way to do it on day one of it's release.
  • by steveha ( 103154 ) on Wednesday March 19, 2014 @03:39PM (#46526845) Homepage

    these implementations pay a penalty for relying on the VM's tracing garbage collection, and this penalty is loss of finalizer functionality.

    And this is why it is best practice in Python to use the with statement, to make sure that things get cleaned up when you are done with them.

    In CPython you can get away with just dropping your objects on the floor, and the reference counting will clean them up for you. In other implementations, not so much.

    This works okay in CPython:

    def read_data(fname):
        f = open(fname)

    In CPython, with no references to f it gets cleaned up, and the open file gets closed.

    In any version of Python, this works great:

    def read_data(fname):
        with open(fname) as f:

    The with statement ensures that the open file will be closed, no matter how the function is exited (including by exception).

    And I actually prefer the with statement these days... I like how it makes the lifetime explicit for the stuff it wraps.

    Raymond Hettinger has expressed the opinion that the with statement is one of the really best ideas in Python. I think that was during his PyCon session where he listed his favorite things in Python.

Nothing is finished until the paperwork is done.