[Python-Dev] PEP 246: lossless and stateless

[Armin Rigo]

Hi Phillip,

On Fri, Jan 14, 2005 at 10:22:36AM -0500, Phillip J. Eby wrote:
> Note that this is solvable in practice by the author of a method or 
> framework choosing to define an interface that they accept, and then 
> pre-defining the adaptation from string to that interface.  So, what a 
> string "means" in that context is pre-defined.

I'm trying to reserve the usage of "interface" to something more concrete: the
concrete ways we have to manipulate a given object (typically a set of methods
including some unwritten expectations).  We might be talking about the same
thing, then, but just to check: I'm making sense of the above paragraph in two
steps.  First, I read it with "interface" replaced by "concept": the author of
the method chooses what concepts the input arguments carry: a file or a file
name, for example.  Then he chooses which particular interface he'd like to
access the input arguments through: if it's a file, then it's probably via the
standard file-like methods; if it's a file name, then it's probably as a
string.  It's important to do it in two steps, even if in practice a lot of
concepts typically comes with a single associated interface (both together,
they are a "duck type").

The programmer using existing methods also goes through two steps: first, he
considers the "intuitive" signature of the method, which includes a reasonable
name and conceptual arguments.  Then he traditionally has to care about the
precise interface that the callee expects.  For example, he knows that in some
specific situation he wants to use marshal.load[s](something), but he has to
check precisely which interface the function expects for 'something': a file
name string, a file-like object, a real file, a content string?

Adaptation should make the latter part more automatic, and nothing more.  
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".

What I see in most arguments about adaptation/conversion/cast is some kind of
confusion that would make us believe that the concrete interface (or even
worse the formal one) fully defines what underlying concepts they represent.  
It is true only for end-user application-specific classes.

> The interpretation problem for strings comes only when a third party 
> attempts to define adaptation from a string to a context that takes some 
> more generic interface.

In the above example, there is nothing in the general concept that helps the
caller to guess how a plain string will be interpreted, or symmetrically that
helps the callee to guess what an incoming plain string means.  In my opinion
this should fail, in favor of something more explicit.  It's already a problem
without any third party.

> >(...) conversion locally.
> 
> 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!


Armin