
On Sat, Jan 09, 2016 at 09:55:08AM -0500, Neil Girdhar wrote:
I think this is admirable. I also dream of faster Python. However, we have a fundamental disagreement about how to get there. You can spend your whole life adding one or two optimizations a year and Python may only end up twice as fast as it is now, which would still be dog slow. A meaningful speedup requires a JIT. So, I question the value of this kind of change.
I think that's pessimistic and unrealistic. If Python were twice as fast as it is now, it would mean that scripts could process twice as much data in the same time as they do now. How is that not meaningful? Sometimes I work hard to get a 5% or 10% improvement in speed of a function, because it's worth it. Doubling the speed is something I can only dream about. As for a JIT, they have limited value for code that isn't long-running. As the PyPy FAQ says: "Note also that our JIT has a very high warm-up cost, meaning that any program is slow at the beginning. If you want to compare the timings with CPython, even relatively simple programs need to run at least one second, preferrably at least a few seconds." which means that PyPy is going to have little or no benefit for short-lived programs and scripts. But if you call those scripts thousands or tens of thousands of times (say, from the shell) the total amount of time can be considerable. Halving that time would be a good thing. There is plenty of room in the Python ecosystem for many different approaches to optimization. [...]
It makes it more complex because you're adding a user-facing property. Every little property adds up in the cognitive load of a language. It also means that all of the other Python implementation need to follow suit even if their optimizations work differently.
That second point is a reasonable criticism of Victor's idea.
What is the point of making __version__ an exposed property? Why can't it be a hidden variable in CPython's underlying implementation of dict?
Making it public means that anyone can make use of it. Just because Victor wants to use it for CPython optimizations doesn't mean that others can't or shouldn't make use of it for their own code. Victor wants to detect changes to globals() and builtins, but I might want to use it to detect changes to some other dict: mydict = {'many': 1, 'keys': 2, 'with': 3, 'an': 4, 'invariant': 5} v = mydict.__version__ modify(mydict) if v != mydict.__version__: expensive_invariant_check(mydict) If Victor is right that tracking this version flag is cheap, then there's no reason not to expose it. Some people will find a good use for it, and others can ignore it. -- Steve