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

[Paul Prescod]

Uche Ogbuji wrote:
> 
> It would appear from the above that every language ever
> written has "interface" (there are usually contraints to the use of
> constructs in every language).  What's special about Python in that
> regard?  

Python is special in that it has 

 a) an idea that objects of different types can be interchangable for each
other, even if they do not share a common base class (other than
PyObject).

and 

 b) that the categories of interchangability can be named. Today we name
them "protocols." Tomorrow we will name them "interfaces." I don't think
that the name change implies a change to the underlying idea. (does it?)

Smalltalk doesn't allowing like that. C++ STL has an implicit (not
language-enforced) concept that is similar (i.e. random-access iterator).
Java's interfaces also capture some part of the problem.

All I am asking as the next step is that it should be possible 

 a) to define new categories of interchangability

 b) to ask an object what its categories of interchangability
("interfaces", or "protocols") are. What exactly do you dislike about
being able to ask that question? 

Actually, I've been more annoyed about the lack of ability to ask about
interfaces in terms of introspection instead of safety. For instance it
annoys me that the Python Object Browser can browse the built-in types,
and even C extension types, but not my Python-created sequence and mapping
types. Argh. Now once the introspection feature is installed, I admit that
I will likely use it to do runtime checks in cases where I think the
caller is likely to make a mistake. If I'm controlling a nuclear plant, I
want an explicit statement from the caller to the ShutDown() method that
they understand that the first argument is some form of ShutDownController
object and not some form of MeltDownController object.

> If you think anyone is arguing against a method for
> communicating and enforcing such constraints, I haven't heard that
> argument.  I have misgivings specifically against what Java calls
> "interfaces", and the sort of derivative idea I heard at the
> Developer Day.

I'm a little lost, because I'm not clear what exactly you dislike about
the strawperson proposal.

> If I could compile this out of Python at installation, I don't
> suppose I would complain.  I don't have anything against others
> getting language features that they desire, but I would rather not
> carry the baggage of such features in the interpreter if I never
> intended to use them.  

Let me see if I understand you right: you would be bothered by the mere
fact that the compiler caught some issues that were *explicitly errors* at
compile time instead of runtime:

a="abcd"
for i in range( a ):
     ...

Would the overhead of checking this at compile time bother you? Even if it
increased performance at runtime? And would it also bother you if you were
allowed to provide some hints so that the compiler could recognize when
your myrange() function was wrongly applied to a
myInternationalizedString?

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

A traceback is better than an unadorned exception. An exception is
better than a naked core dump. A core dump is better than silent
failure. Success beats all. Is Python the next step up your language
ladder?