Slashdot Mirror
Python 3.4 Released
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."
That would be nice.
And everyone will keep using 2.6/2.7, the windows XP of python.
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
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.
I have recently started bathing in the waters of Python. What I have realized is that it is a core group within Python who are rightfully proud of their 3.x accomplishment. But they are solidly ignoring the fact that only a tiny percentage of people are using it. The reasons are quite simple people will need 8 modules for their system and 1 barely works with 3.x and the other says something like "mostly works" Well most people aren't willing to depend upon "mostly".
Now module after module is going 3.x but the other problem is that for most people having two pythons on their machine is a pain in the ass. I know there are tools to make this less painful but I can tell you an easy way to make it painless, Don't have two versions.
Then there is this call that you should begin new projects in 3.x; but the problem again is the two versions issue.
What bothers me about all this is that I come from a C++ / PHP world. With C++ I have upgraded countless times over many years and had close to zero problems with my code. I don't even know which compiler XCode is even using right now. With PHP my various upgrades have broken exactly one module and I hear rumours that the next big version of PHP will break one module in my older code. But I don't care as I am replacing my PHP with Python.
Where I am worried is that the core Python people will do something stupid like announce an end of support date for 2.7. The problem there is that it might be easier for some people to install a whole different language to sit alongside Python 2.7 and start playing with that instead of smashing their machine in the teeth and simultaneously installing 3.x.
Have they fixed the whitespace bug yet?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
And python has supported it (at least on unix) virtually since it was first released.
I've never really seen much virtue in multi threading - its useful in a limited number of cases but usually it creates more problems than it solves (compared to multi process) and is usually used by people who don't really know what they're doing. Essentially multi threading takes all the advantages of protected process virtual memory and throws them in the bin.
Which isn't a bad thing. Perl, Python, and Ruby do not run natively within a CPU. Both Python and Ruby settled on a GIL so that the interpreter could have multiple threads of execution. Perl decided that it would be faster to just give each thread its own interpreter and they were right. You can also do cool things like detach long lived threads and whatever.
You can still fork in Python, Perl, and Ruby and give each process its own independent address space and use IPC to share data. However with Perl threads you can share variable data (with caveats) with multiple threads with threads::shared.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
well, there is a good solution.. don't run multiple threads in a single memory space. The problem with people complaining about the GIL is they are coming at it from the wrong direction. The problem is people want multiple threads all able to mess with each other's data and not bother with all that pesky IPC or locking, which yes it is quicker and easier, but causes a lot of frustrating problems that people have forgotten they do not actually need to have.
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.
lf(1): it's like ls(1) but sorts filenames by extension, tersely