myths about python 3
alex23
wuwei23 at gmail.com
Thu Jan 28 21:56:11 EST 2010
Terry Reedy <tjre... at udel.edu> wrote:
> This statement was to counter the 'myth' that US was only targeted at
> 2.x when the current situation is quite the opposite.
Not so much 'myth' as 'outdated information', they were very clear
that 2.x was the initial target.
> In particular, several people said that the speed/space traceoff
> should be optional, and that compilation 'without llvm' should really
> be without, not just with llvm present but disabled. Instead of arguing,
> Colin went ahead and patched the build process to make it be this way.
Ah, that's excellent. The impression being given off is that it's a
total replacement.
> I have no idea. It will have to improve its speedup more before
> adoption. I will not be surprised if that happens.
It's not so much about being surprised or not, it's wanting actual
evidence and not just claims, and moreso _extensive real world usage_
before it's integrated. This seems far more intimate a change than
adding a module to the stdlib, I expect it to have at _least_ the
evaluation time & vague consensus of approval expected of those.
> US is not a new or separate interpreter. It will be an optional jit
> replacement for one component of CPython, the eval loop. All the code
> for builting functions, types, and modules will be untouched, as will
> their big O performance characteristics.
As long as there aren't any related decreases in performance in other
areas, I'll be happy.
> If you can still have a binary free of the traceoff, why would you care?
Well, I didn't know I could, so now I don't quite as much :)
> They claim they have pretty well fixed that. They know that complete
> Windows support, including 64 bit versions, is a necessity.
Maybe I'll be a lot more convinced after the Q4 report.
The 'incomplete' Windows support may not be as big an issue as I
thought, it seems to refer to a lack of support for older Windows
versions rather than an incomplete implementation on the supported
ones.
Cheers, Terry, this addressed a lot of my concerns, although I'm still
keen to see more facts & real-world usage over custom-crafted
benchmarks and enthusiastic claims.
More information about the Python-list
mailing list