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

[Neil Girdhar]

I read through this thread and just want to quickly address some good
points.

First of all, I didn't mean to suggest that this kind of optimization is
not useful.  Of course, I will be thankful of any optimization that makes
it into CPython.  Making CPython faster is good, useful work.   It's just
that my dream of the future of Python is one where Python is faster than C
thanks to a very clever JIT.

> I agree with Neil Girdhar that this looks to me like a CPython-specific
> > implementation detail that should not be imposed on other
> > implementations.  For testing, perhaps we could add a dict_version
> > function in test.support that uses ctypes to access the internals.
> >
> > Another reason to hide __version__ from the Python level is that its use
> > seems to me rather tricky and bug-prone.
> What makes you say that? Isn't it a simple matter of:
> v = mydict.__version__
> maybe_modify(mydict)
> if v != mydict.__version__:
>     print("dict has changed")


This is exactly what I want to avoid.  If you want to do something like
this, I think you should do it in regular Python by subclassing dict and
overriding the mutating methods.  What happens if someone uses a custom
Mapping?  Do all custom Mappings need to implement __version__?   Do they
need a __version__ that indicates that no key-value pairs have changed, and
another version that indicates that nothing has changed (for example
OrderedDict has an order, sorteddict has a sort function; changing either
of those doesn't change key-value pairs).  This is not supposed to be
user-facing;  this is an interpreter optimization.


>
> Obviously a JIT can help, but even they can benefit from this. For
> instance, Pyjion could rely on this instead of creating our own guards for
> built-in and global namespaces if we wanted to inline calls to certain
> built-ins.


I understand that, but what if another JIT decides that instead of
__version__ being an attribute on the object, version is a global mapping
 from objects to version numbers?  What if someone else wants to implement
it instead as a set of changed objects at ever sequence point?  There are
many ways to do this optimization.  It's not obvious to me that everyone
will want to do it this way.

>
> C compilers often have optimization levels that can potentially alter the
> program's operation


Some of those optimizations lead to bugs that are very hard to track down.
One of the advantages of Python is that what you pay for in runtime, you
save ten-fold in development time.

In summary, I am 100% behind this idea if it were hidden from the user.

Best,

Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160110/540d2d44/attachment.html>