On Sat, Jul 31, 2010 at 10:12 PM, Antoine Pitrou email@example.com wrote:
On Sat, 31 Jul 2010 13:50:16 +0200 Tarek Ziadé firstname.lastname@example.org wrote:
On Sat, Jul 31, 2010 at 3:31 AM, Nick Coghlan ncoghlan-Re5JQEeQqe8AvxtiuMwx3w@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.