[Python-ideas] RFC: PEP: Add dict.__version__

Steven D'Aprano steve at pearwood.info
Sat Jan 9 22:31:41 EST 2016


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


More information about the Python-ideas mailing list