
On Sun, Jan 10, 2016 at 12:57 PM, Steven D'Aprano <steve@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.
I can already subclass dict to do that now. But if Victor's suggestion is accepted, then I don't need to. The functionality will already exist. Why shouldn't I use it?
Because people write code for the abc "Mapping". What you are suggesting is then to add "__version__" to the abc Mapping, which I am against. Mapping provides the minimum interface to be a mapping; there is no reason that every Mapping should have a "__version__".
What happens if someone uses a custom Mapping?
If they inherit from dict or UserDict, they get this functionality for free. If they don't, they're responsible for implementing it if they want it.
But they shouldn't have to implement it just so that code written for Mappings works — as it does now.
Do all custom Mappings need to implement __version__?
I believe the answer to that is No, but the PEP probably should clarify that.
If the answer is "no" then honestly no user should write code counting on the existence of __version__.
-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
--
--- You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/HP5qdo3rJxE/unsubscribe. To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.