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

[Andrew Barnert]

On Jan 10, 2016, at 10:35, Neil Girdhar <mistersheik at gmail.com> wrote:
> 
>> On Sun, Jan 10, 2016 at 12:57 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> On Sun, Jan 10, 2016 at 11:48:35AM -0500, Neil Girdhar wrote:
>> 
>> [...]
>> > > 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.
>> 
>> That doesn't help Victor, because exec need an actual dict, not
>> subclasses. Victor's PEP says this is a blocker.
> 
> No, he can still do what he wants transparently in the interpreter.  What I want to avoid is Python users using __version__ in their own code. 

Well, he could change exec so it can use arbitrary mappings (or at least dict subclasses), but I assume that's much harder and more disruptive than his proposed change.

Anyway, if I understand your point, it's this: __version__ should either be a private implementation-specific property of dicts, or it should be a property of all mappings; anything in between gets all the disadvantages of both.

If so, I agree with you. Encouraging people to use __version__ for other purposes besides namespace guards, but not doing anything to guarantee it actually exists anywhere besides namespaces, seems like a bad idea.

But there is still something in between public and totally internal to FAT Python. Making it a documented property of PyDict objects at the C API level is a different story--there are already plenty of ways that C code can use those objects that won't work with arbitrary mappings, so adding another doesn't seem like a problem. And even making it public but implementation-specific at the Python level may be useful for other CPython-specific optimizers (even if partially written in Python); if so, the best way to deal with the danger that someone could abuse it for code that should work with arbitrary mappings or with another Python implementation should be solved by clearly documenting it's non portability and discouraging its abuse in the docs, not by hiding it.


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