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

[Neil Girdhar]

On Sat, Jan 9, 2016 at 8:42 AM, Victor Stinner <victor.stinner at gmail.com>
wrote:

> Hi,
>
> 2016-01-09 13:48 GMT+01:00 Neil Girdhar <mistersheik at gmail.com>:
> > How is this not just a poorer version of PyPy's optimizations?
>
> This a very good question :-) There are a lot of optimizers in the
> wild, mostly JIT compilers. The problem is that most of them are
> specific to numerical computations, and the remaining ones are generic
> but not widely used. The most advanced and complete fast
> implementation of Python is obviously PyPy. I didn't heard a lot of
> deployements with PyPy. For example, PyPy is not used to install
> OpenStack (a very large project which has a big number of
> dependencies). I'm not even sure that PyPy is the favorite
> implementation of Python used to run Django, to give another example
> of popular Python application.
>
> PyPy is just amazing in term of performances, but for an unknown
> reason, it didn't replace CPython yet. PyPy has some drawbacks: it
> only supports Python 2.7 and 3.2 (CPython is at the version 3.5), it
> has bad performances on the C API and I heard that performances are
> not as amazing as expected on some applications. PyPy has also a worse
> startup time and use more memory. IMHO the major issue of Python is
> the backward compatibility on the C API.
>
> In short, almost all users are stuck at CPython and CPython implements
> close to 0 optimization (come on, constant folding and dead code
> elimintation is not what I would call an "optimization" ;-)).
>
> My goal is to fill the hole between CPython (0 optimization) and PyPy
> (the reference for best performances).
>
> I wrote a whole website to explain the status of the Python optimizers
> and why I want to write my own optimizer:
> https://faster-cpython.readthedocs.org/index.html


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.

>
>
> > If what you want is optimization, it would be much better to devote time
> to a solution
> > that can potentially yield orders of magnitude worth of speedup like PyPy
> > rather than increasing language complexity for a minor payoff.
>
> I disagree that my proposed changes increase the "language
> complexity". According to early benchmarks, my changes has a
> negligible impact on performances. I don't see how adding a read-only
> __version__ property to dict makes the Python *language* more complex?
>
>
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.

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?  If
some code needs to query __version__ to see if it's changed then CPython
should be the one trying to discover this pattern and automatically
generate the right code.  Ultimately, this is just a piece of a JIT, which
is the way this is going to end up.

My whole design is based on the idea that my optimizer will be
> optimal. You will be free to not use it ;-)
>
> And sorry, I'm not interested to contribute to PyPy.
>

That's fine, but I think you are probably wasting your time then :)  The
"hole between CPython and PyPy" disappears as soon as PyPy catches up to
CPython 3.5 with numpy, and then all of this work goes with it.


>
> Victor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160109/cef92290/attachment.html>