[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