[Python-ideas] Exposing the ABC registration graph (was Re: Json object-level serializer)
Nick Coghlan
ncoghlan at gmail.com
Sat Jul 31 17:26:20 CEST 2010
On Sat, Jul 31, 2010 at 10:12 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 31 Jul 2010 13:50:16 +0200
> Tarek Ziadé <ziade.tarek at gmail.com> wrote:
>> On Sat, Jul 31, 2010 at 3:31 AM, Nick Coghlan <ncoghlan-Re5JQEeQqe8AvxtiuMwx3w at 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
> registry?
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.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas
mailing list