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."
and... (Score:5, Insightful)
And everyone will keep using 2.6/2.7, the windows XP of python.
And it still has the GIL (Score:1, Insightful)
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.
Re:And it still has the GIL (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/ [jeffknupp.com]
https://www.jeffknupp.com/blog/2013/06/30/pythons-hardest-problem-revisited/ [jeffknupp.com]
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)
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.
Re:Python is the new Pascal (Score:3, Insightful)
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.
No.
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)
> 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)
Re:Reference counting and unmanaged resources (Score:4, Insightful)
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)
return f.read()
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:
return f.read()
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.