[Python-3000] Adaptation [was:Re: Iterators for dict keys, values, and items == annoying :)]

[Nick Coghlan]

Alex Martelli wrote:
> Do we have a "good practice document" about what you should or shouldn't 
> do with metaclasses, or decorators, or, for that matter, with 
> inheritance, operator overloading, and other powerful constructs and 
> tools that have been with Python a long, long time?

Fair cop - I can accept that adaptation really isn't any more dangerous than 
some of Python's existing magic mechanisms, and abuse can be slapped down the 
same way (i.e. peer review).

It may not make your head hurt less, but I really think you're making cracks 
in that wall of incomprehension this time around ;)

> I don't think this other tweak would be a _big_ "bother", but neither 
> would it be at all useful, just a medium-level useless bother.
> 
> Say, for example, that protocols are identified (as in my strawman 
> proposal) by unique strings anyway. E.g., if I were to invent a 
> protocol, I could name it 'it.aleax.myprot' -- since I own the aleax.it 
> domain, nobody else could create a name conflict.

But if everbody is using a global registry, this still creates the need for a 
(new) globally adopted convention for avoiding name conflicts, be it "use 
reverse-DNS naming" or "always use unique objects with identity based 
equality". My point is that instead of creating a new convention to avoid 
namespace conflicts for protocols, we should try to reuse an existing one - 
the Python import mechanism.

Starting from that perspective, I *really* like Walter's suggestion of using 
the protocol itself to store a per-protocol adapter registry. Protocols are 
identified unambiguously (using the Python import namespace), and once you 
have access to the protocol object there's no extra work to find its registry.

> I may be missing something here, I guess, because I just don't see the 
> point.

Walter's suggestion was what I was groping towards, but hadn't reached yet (my 
next suggestion was going to be that a protocol should know where its registry 
lived).

As for why I cared in the first place, when I see a suggestion to add more 
interpreter global state I want to see a *really*, *really* good justification 
for it. In this case, it makes far more sense to me to move the adapter 
registration out to the individual protocols.

> Isn't it just wonderful, how the foes of adaptation switch horses on 
> you?  First they request a simple-as-dirt, bare-bones "example system" 
> -- then as soon as you provide one they come back at you with all sort 
> of "cruft" to be piled on top.

99% of my resistance stemmed from my objection to the global protocol registry 
that added the need for an entirely new convention for avoiding name conflicts 
between different registered protocols. If we can pursue an approach that 
pushes adaptation registration out to the protocols themselves, then I am 100% 
in favour of the idea :)

In a glorious fit of self-referentiality, one of the first things needed by 
such an approach would be a protocol for the protocol interface that allowed 
other protocol objects to register themselves as implementing it. This would 
then allow the ever popular generic adaptation function to be written as:

   def adapt(obj, target_protocol):
       return Protocol.adapt(target_protocol).adapt(obj)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org