[PEAK] PyProtocols: adapting None

Marko Mikulicic marko at autistici.org
Thu Mar 30 13:55:54 EST 2006


On 30.03.2006., at 20:08, Phillip J. Eby wrote:
>
> I'm saying that having a special AdaptedNone for this purpose is  
> not specified in the PEP, so anything that returns AdaptedNone  
> isn't necessarily usable with different PEP 246 implementations.
>
> So, you'd have to lobby the PEP author before I'd be interested in  
> changing this, especially since the change isn't worth it for the  
> use case, which can be handled in other ways.  For example, you can  
> just define your interface to have a method that returns the object  
> to use.  Then when you adapt None to that interface, the adapter  
> just has a method that returns the adapted object.

The problem is that I have to pass None to existing third-party code  
that does things like "if blabl is None:...."
so it has to be the real None.

My point is that the PEP limit just the API of the factory. Normal  
"users" of the adapter doesn't even see the AdaptedNone
(or some other means to escape a value from this None = failure  
shortcut). Since code that needs this will not work in other  
implemenations
anyway I think that adding this could not harm.

However if there is another way to "hook" an escape (without calling  
it AdapterNone), in the adapt() function so that applications that  
need this
can implement their own NO_ADAPTER_NEEDED. The problem is really only  
in the fact that adapt code is optimized in pyrex and hardcoded so that
is not extensible enough (without compromising performance). For  
example the Protocol__call__ function implemented in pyrex bypasses  
the python adapt function even if monkeypatched and calls directly  
the _adapt method. I could monkeypatch it too but perhaps in the next  
revision you add some new optimization etc

How many implementation of PEP 246 are there? (PyProtocols, twisted  
interfaces, zope?)



More information about the PEAK mailing list