[Types-sig] RE: PRE-PROPOSAL: Python Interfaces

Gordon McMillan gmcm@hypernet.com
Sun, 22 Nov 1998 22:45:20 -0500


[Gordon]
> > OK, so lets pretend that's cleaned up. Now we're getting methods on
> > List so it can be treated like a Stack. Stack is certainly not
> > another name for List, nor for Sequence (whatever that means). It's
> > another protocol, right? But it's one that is automatically
> > implemented if you implement the List protocol.

[Uncle Timmy] 
> Under the proposal, though, conformance isn't a matter of checking
> structural equivalence of method collections, it's a matter of
> looking for specific interface objects in constrained places.  So if
> you have
> 
>     class Stack(Interface):
>         def push(self, thing): MysteryGoesHere
>         def pop(self): MysteryGoesHere
> 
> then it's simply consequence-free coincidence if "class
> List(Interface)" contains methods with matching names and signatures
> -- unless List.__implements__ contains specifically Stack.
> 
> IOW, Lists do *not* implement the Stack protocol just because "it
> looks like" they do -- if they do at all, it's only by virtue of
> List explicitly saying it implements specifically Stack.  Today,
> though, there's no way to draw the distinction at all.

Which brings up the point Paul made that if the all-omiscient Guido 
forgot to say that (the builtin) List implements Stack, and his time 
machine will have been in the body shop because of that 
fender-bender, then I'd better be able to say at runtime that "I know 
this is a List, but you'll treat it like a Stack anyway".

> OTOH, unlike e.g. JimF I have nothing against stuffing some default
> implementation into interfaces.  

Yeah. Somehow my C++ "abstract base classes" always end up not being
abstract.

[snip]

> [point 14 from Timmy's egroups manifesto]

Which Basilica door did you nail this to? (IE, where can I read it?)
 
> 14. [folklore is purged from the core] Enough sensible builtin
> "marker classes" are provided so that the documentation for every
> builtin function and builtin method can, for every argument, say
> that (at least) instances of such-and-such a builtin class are
> accepted.
[snip]
> People simply don't know what "pass something that acts like a
> sequence" or "acts like a file" etc *means*, and it turns out an
> accurate answer is sometimes darned hard to give.

I will admit to being completely mystified by the following (from 
lib/module-select.html):

"You may also define a wrapper class yourself, as long as it has an   
  appropriate fileno() method (that really returns a Unix file     
  descriptor, not just a random integer)."

particularly-on-WIndows-ly y'rs


- Gordon