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

Gregory P. Smith greg at krypto.org
Mon Jan 11 17:53:25 EST 2016


On Fri, Jan 8, 2016 at 11:44 PM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 9 January 2016 at 16:03, Serhiy Storchaka <storchaka at gmail.com> wrote:
> > On 08.01.16 23:27, Victor Stinner wrote:
> >>
> >> Add a new read-only ``__version__`` property to ``dict`` and
> >> ``collections.UserDict`` types, incremented at each change.
> >
> >
> > This may be not the best name for a property. Many modules already have
> the
> > __version__ attribute, this may make a confusion.
>
> The equivalent API for the global ABC object graph is
> abc.get_cache_token:
> https://docs.python.org/3/library/abc.html#abc.get_cache_token
>
> One of the reasons we chose that name is that even though it's a
> number, the only operation with semantic significance is equality
> testing, with the intended use case being cache invalidation when the
> token changes value.
>
> If we followed the same reasoning for Victor's proposal, then a
> suitable attribute name would be "__cache_token__".
>

+1 for consistency.  for most imaginable uses the actual value and type of
the value doesn't matter, you just care if it is different than the value
you recorded earlier. How the token/version gets mutated should be up to
the implementation within defined parameters such as "the same value is
never re-used twice for the lifetime of a process" (which pretty much
guarantees some form of unsigned 64-bit counter increment - but an
implementation could choose to use 256 bit random numbers for all we really
care).  Calling it __version__ implies numeric, but that isn't a
requirement.

we _really_ don't want someone to write code depending upon it being a
number and expecting it to change in a given manner so that they do
something conditional on math performed on that number rather than a simple
== vs !=.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160111/7c5af46b/attachment.html>


More information about the Python-ideas mailing list