On Sat, Jul 31, 2010 at 10:12 PM, Antoine Pitrou <solipsis(a)pitrou.net> wrote:
> On Sat, 31 Jul 2010 13:50:16 +0200
> Tarek Ziadé <ziade.tarek(a)gmail.com> wrote:
>> On Sat, Jul 31, 2010 at 3:31 AM, Nick Coghlan <ncoghlan-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote:
>> > To be honest, there are actually some more features I would want to
>> > push for in ABCs (specifically, a public API to view an ABC's type
>> > registry, as well as a callback API to be notified of registration
>> > changes) before seriously proposing an official generic function
>> > implementation in the standard library.
>> funny hazard, I was proposing to PEP 3319 authors about having the
>> _abc_registry attribute
>> somehow exposed.
> Rather than exposing the registry object itself (which is an
> implementation detail), how about exposing lookup operations on this
There's a related problem here that ties into one of the complaints I
have with pkgutil.simplegeneric: because that decorator relies on MRO
traversal in order to obtain a reasonably efficient implementation, it
completely ignores any ABC registrations. That's fairly suboptimal,
since a comparable chain of "isinstance()" checks *will* respect ABC
registrations (it's just horrendously slow and doesn't scale, since
the worst-case number of checks increases linearly with the number of
branches in the if-elif chain).
So I think the idea of query methods in the abc module is a good way
to go. It allows the Python implementation freedom in choosing whether
to have separate type registries stored on the ABCs themselves, or
instead have global registries stored in the abc module. In
particular, it allows the interpreter to cache the transitive closure
of the ABC graph, such that an application can ask for the set of all
objects that implement a given ABC, as well as the set of all ABCs
that a given object implements.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia