[Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

Nick Coghlan ncoghlan at gmail.com
Sat May 25 16:59:09 CEST 2013


On Sun, May 26, 2013 at 12:08 AM, PJ Eby <pje at telecommunity.com> wrote:
> On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa <lukasz at langa.pl> wrote:
>> The most important
>> change in this version is that I introduced ABC support and completed
>> a reference implementation.
>
> Excellent!  A couple of thoughts on the implementation...
>
> While the dispatch() method allows you to look up what implementation
> would be *selected* for a target type, it does not let you figure out
> whether a particular method has been *registered* for a type.
>
> That is, if I have a class MyInt that subclasses int, I can't use
> dispatch() to check whether a MyInt implementation has been
> registered, because I might get back an implementation registered for
> int or object.  ISTM there should be some way to get at the raw
> registration info, perhaps by exposing a dictproxy for the registry.

I like that idea - types.MappingProxyType makes it straightforward to
expose a read-only view of the dispatch registry.

> Second, it should be possible to memoize dispatch() using a weak key
> dictionary that is cleared if new ABC implementations have been
> registered or when a call to register() is made.  The way to detect
> ABC registrations is via the ABCMeta._abc_invalidation_counter
> attribute: if its value is different than the previous value saved
> with the cache, the cache must be cleared, and the new value stored.
>
> (Unfortunately, this is a private attribute at the moment; it might be
> a good idea to make it public, however, because it's needed for any
> sort of type dispatching mechanism, not just this one particular
> generic function implementation.)

I think I added an issue on the tracker for that somewhere... yup:
http://bugs.python.org/issue16832

Given the global nature of the cache invalidation, it may be better as
a module level abc.get_cache_token() function.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list