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

[Gordon McMillan]

[Gordon]
> > I don't object, but I worry. For example, the "sequence protocol" is
> > a very fuzzy thing.

[Paul]
> Let me see if I understand your concern: imagine that you have code
> that does not require the full List interface. You only require some
> sub-part of it - read-only list. A client has code that implements
> read-only list. Under the current system, the client programmer
> could read the docs or code, take note that the read-only list is
> good enough, and pass it in. The interface is not checked by the
> computer, so we can work around the holes in the interface hierarchy
> by adopting out-of-band conventions.

That last sentence is a sneaky piece of rhetoric. More accurate, and 
almost as misleading, to say that the required interface has been 
completely spelled out by the methods that are called.

> In the C++ templates world, the compiler would do static interface
> checking of the instantiation of the template and if nothing breaks,
> it will just work.

This is actually a criticism of C++ templates. Nowhere is it spelled 
out that "tempate<T> blah blah" requires that T implement 
spam_spam_eggs_and_spam(). You find out by reading the source. Or if 
you're like me, by reading the error message. Which is the way I find 
out, in Python, that the object I passed in doesn't do the job.

Java interfaces spell it out, but make unwarranted assumptions about  
inheritance, and don't generate code. Of course, a C++ template 
generates code to handle what we Pythoneers can do directly, so we 
don't need to generate code. (Yet.)

> ... it doesn't
> make sense for the Python standard library to try and express every
> variant of list.

That's a fair statement of concern #1.  Concern #2 is that it's 
really only "optional" if I can use your function (which wants an 
object which implements the ReEnactsPearlHarborInAMudField interface) 
with any old thing I choose, and take my lumps at runtime.

[snip snip - I bring up another odd-ball "interface"]

> We may or may not be able to do that with type signatures or any
> other formalism, but we can certainly do it with prose. That's what
> C++ does:
> 
> http://www.cs.rpi.edu/projects/STL/htdocs/node53.html

I don't think STL makes a good model for anything we are trying to 
do. For one thing, while STL is very powerful, it actually makes some 
simple things harder. For another, most of it's power is in making a 
statically typed language behave (as far as coding is concerned) like 
a dynamically bound one. Mostly, STL generates code so you can write 
typeless templates and get fully typed instanciations. Maybe we'll 
need that in SPython, but not in Python.
 
> As Jim Fulton has said, even this:
> 
> interface FileInput:
>  "This is a read-only, forward-only, sequential-only sequence."
> 
> is better than lore shared on a newsgroup, which is what we have
> today.

I realize fully that this is a strong argument for many. It's not for 
me. And a deft twist of Occam's Razor might yield the conclusion that 
an EmptyDocStringException is a better solution <wink>.

> Right, and we need a way of talking about the subsets that we are
> actually interested in. And we need to be able to define those
> susets more or less "on the fly" when we need them, instead of
> building top-down.

I'll buy that conclusion.

I'm about 50% playing devil's advocate, and trying to make sure 
people know what they're buying. But the other 50% of me is serious.

When I write a GUI app, for example, I'm all in favor of 
optimization (and safety) on the data / "application" logic side. But 
I tend to use heavily dynamic GUI code. There's no reason to optimize 
GUI code. As for "safety":

[out of order snippet]:
> is better than just trusting that caller understood that the
> argument was supposed to be a FileInput type. And if we check
> method signatures, then we have gone even farther to prove that the
> caller understands what is going on. And if we can solve the
> halting problem, we could demonstrate beyond a shadow of a doubt
> that the caller knew exactly what he or she was doing. But as Skip
> says, let's put the halting problem aside for a moment.

"caller understands", "caller knows", well excuuuuuse me, but I'm the 
caller, and if I can trick your code into doing what I want even if 
it's not what you expected, then more power to me!

and-a-specific-solution-to-the-halting-problem-is-found-when
-it-doesn't-blow-up-in-my-face-ly y'rs

- Gordon

PS And yes, I know you'll never find the general solution this way...