[Python-Dev] Revive the types sig?

[Paul Prescod]

Paul Moore wrote:
> 
> ....
> 
> I wasn't suggesting "total" polymorphism (although I did overstate my case a
> bit). What I was pointing out was essentially that it is possible to define
> totally "plug-compatible" replacements for builtin types, and have them work
> everywhere the built-in type does. With the exception of code that does "if
> type(x) != type(1)".

I think that making plug-compatible subclasses for the built-in types is
extremely difficult and rarely accomplished. The built-in types aren't
even plug-compatible with each other: integers can't be used everywhere
floats can nor vice versa. Sometimes you get lucky. Sometimes you don't.
For instance can you today make a non-integer object that can be used as
an index for a standard Python list? I would be surprised.

It's important to remember that Python objects do not typically go very
long before being passed into the C layer. And the C layer already has a
strict dynamic type annotation system.

Another idea: type annotations move you CLOSER to the world of total
type interoperability because it provides an obvious place to hook in
conversion code from your "int-like" object to a real integer that
really could be used to index a list.

>...
> Of course, if type annotations will *actually* formalise and support
> interfaces in some form, that's entirely different - I'm mostly neutral, about
> something like this.
> 
>     def f(n):
>         assert <n supports the "integer" interface>

Yes, type annotations will certainly support interfaces/protocols or
whatever you want to call them. On the other hand, after a first stab at
protocols for basic numeric types I gave up. Python is not quite that
flexible and polymorphic.

I'm not sure if any language is that flexible. One of the defining
characteristics of the basic types such as integer and long is that
Python knows how to manipulate their bit patterns in memory. The only
way you could make a type that behaves "exactly like an integer" is to
have a conversion to an integer -- which isn't quite the same.

>...
> My concern is that over-use of assertions like this limit "creative use" of
> functions, in contexts which the author may never have envisioned.

There are two different issues here. One is "creative use" where a
sophisticated programmer understands all of the code being used and is
confident that an object will "just work" despite the fact that the code
was not designed to be polymorphic. Most often, under a more strongly
checked type system, you would use inheritance to make this work in the
future.

The second issue are documented functions or methods that work with a
variety of objects that "look the same." In this case, the type system
uses interfaces to formalize what you've already being doing.

> The best example to date in Python is "file-like" objects. There are *lots* of
> library functions which take such objects. Not just files, but also
> user-defined objects which act like files. And many such functions explicitly
> state that they only require a subset of the full file interface. (Often not
> requiring seekability, sometimes requiring nothing more than readline).

Yes, this will use interfaces. Remember that a ton of modules that work
on file-like objects are *already type-checked*. They are C extensions
that pass their data through PyArg_ParseTuple.

-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.activestate.com/pythoncookbook