I find your claims are unsubstantiated and would require some evidence to be convincing.
For example, the performance of Python 3.0 was slow on I/O operations. The reason was because the I/O modules were written in pure-python in order to get the ball rolling. This wasn't a bug. However, the code was eventually ported to C in 3.1 and unsurprisingly the performance improved: http://www.gtsystem.eu/blog/2009/08/improved-performance-of-...
And that's an old post from 2009! The performance is much better today.
Features they're releasing in this new version include zero-copy in os.copyfile() which is totally sweet. No user-space buffers involved in transferring bytes from a file to a socket. This should speed up such operations well past what any version of python 2.x is capable of.
There isn't a feature in Python 3 that is not substantially better than 2.x -- they're fixing all the fiddly bits and producing a much better language. There is no feature they can create which will open the dam to a flood of porting projects. The reason is that the problem is a social one.
An honest-to-goodness effort to port the large libraries requires a plan to support the existing 2.x versions alongside the 3.x versions so that the people who are still running applications built on the old versions will still work. This requires extra effort that is difficult to acquire in open source projects let alone commercial ones.
Even if the Python 3 devs added a feature that materialized ponies out of thin air there would still be projects running the 2.x code.
> I find your claims are unsubstantiated and would require some evidence to be convincing.
It's been 3+ years since Python 3.0 has been released, and, while I agree that there's no "substantiated evidence" for its demise, some of us who witnessed the whole Zope2 to Zope3 "transition" know that in the end "evidence" doesn't count at all. What count are actual smart people, lots of them preferably, building cool and useful things with the new tool.
Yep. I won't port a single bit of my existing code until 100% of the libraries I depend on are ported first. As much as I like Python 3, it just doesn't make any sense for me to deal with it right now.
Part of what I was trying to get across is that there will never be a compelling reason to make the port. It will never "make sense" so long as what you have now continues to work.
If you're ever going to make the port, you have to decide to do it and make the effort. Nothing the Python 3 devs release will ever convince you to port otherwise.
For example, the performance of Python 3.0 was slow on I/O operations. The reason was because the I/O modules were written in pure-python in order to get the ball rolling. This wasn't a bug. However, the code was eventually ported to C in 3.1 and unsurprisingly the performance improved: http://www.gtsystem.eu/blog/2009/08/improved-performance-of-...
And that's an old post from 2009! The performance is much better today.
Features they're releasing in this new version include zero-copy in os.copyfile() which is totally sweet. No user-space buffers involved in transferring bytes from a file to a socket. This should speed up such operations well past what any version of python 2.x is capable of.
There isn't a feature in Python 3 that is not substantially better than 2.x -- they're fixing all the fiddly bits and producing a much better language. There is no feature they can create which will open the dam to a flood of porting projects. The reason is that the problem is a social one.
An honest-to-goodness effort to port the large libraries requires a plan to support the existing 2.x versions alongside the 3.x versions so that the people who are still running applications built on the old versions will still work. This requires extra effort that is difficult to acquire in open source projects let alone commercial ones.
Even if the Python 3 devs added a feature that materialized ponies out of thin air there would still be projects running the 2.x code.