[Python-Dev] PEP 246: lossless and stateless

[Clark C. Evans]

On Fri, Jan 14, 2005 at 04:39:00PM +0000, Armin Rigo wrote:
| 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).  

I'd say that a programmer interface intends to encapsulates both the
'concept' and the 'signature'.  The concept is indicated by the
names of the function delcarations and fields, the signature by the
position and type of arguments.

| Adaptation should make [passing data between conceptually equivalent 
| interfaces?] 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".

But it is quite difficult to know when two interfaces are conceptually
equivalent...

| 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.

It seems your distinction comes down to defining 'best pratice' for
when you define an adapter... and when you don't.   Perhaps we don't
need to qualify the adapters that exist, as much as make them
transparent to the programmer.  A bad adapter will most likely be
detected _after_ a weird bug has happened.  Perhaps the adapt()
framework can provide meaningful information in these cases.

Imagine enhancing the stack-trace with additional information about
what adaptations were made; 

    Traceback (most recent call last):
       File "xxx", line 1, in foo
         Adapting x to File
       File "yyy", line 384, in bar
         Adapting x to FileName
       etc.

| 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.

How can we express your thoughts so that they fit into a narrative
describing how adapt() should and should not be used?  If you could
respond by re-posting your idea with the 'average python programmer'
as your audience it would help me quite a bit when summarizing your
contribution to the thread.

Best,

Clark