Home Original page

[Python-Dev] PEP 246: lossless and stateless

Phillip J. Eby pje at telecommunity.com
Fri Jan 14 18:36:12 CET 2005 
At 04:39 PM 1/14/05 +0000, Armin Rigo wrote:
>Ideally, both the caller and the callee know (and write down) that the
>function's argument is a "reference to some kind of file stuff", a very
>general concept; then they can independently specify which concrete object
>they expect and provide, e.g. "a string naming a file", "a file-like object",
>"a string containing the data".

Yes, exactly!  That's what I mean by "one use case, one interface".  But as 
you say, that's because we don't currently have a way to separate these ideas.

So, in developing with PyProtocols, I create a new interface for each 
concept, possibly allowing adapters for some other interface to supply 
default implementations for that concept.  But, for things like strings and 
such, I define direct adapters to the new concept, so that they override 
any "generic" adapters as you call them.

So, I have a path that looks like:

concreteType -> functionalInterface -> conceptInterface

Except that there's also a shorter concreteType -> conceptInterface path 
for various types like string, thus providing 
context-sensitivity.  (Interestingly, strings are the *most* common 
instance of this situation, as they're one of the most "open to 
interpretation" objects you can have!)


> > It also works for the module to define a target interface and register an
> > adapter to that, and introduces less complexity into the adaptation system.
>
>Makes sense, but my fear is that people will soon register generic adapters
>all around...  debugging nightmares!

Well, if you have "interface per concept", you *have* a context; the 
context is the concept itself.
More information about the Python-Dev mailing list