[Python-Dev] Revive the types sig?

[Paul Moore]

On Wed, 14 Mar 2001 15:55:38 +0100, Paul Prescod <paulp at ActiveState.com>
wrote:
>Paul Moore wrote:
>> My view on all this is that type annotations are likely to be counterproductive,
>> in the face of Python's high degree of polymorphism. For example, what is the
>> type of
>> 
>> def fac(n):
>>     if n <= 1: return 1
>>     return n * fac(n-1)
>> 
>> ?
>> 
>> Obvious answer, integer -> integer. And that's likely what the programmer would
>> say.
>> 
>> But why can't this function be used with *any* type which supports comparison
>> with the number 1, multiplication, and subtraction of 1?
>
>Sure it can. But as a programmer, I probably haven't really thought
>through the meaning of this code for users who pass in strings or lists
>of SocketObjects. Therefore I should not be blamed when someone passes
>in a random type and gets strange behavior.

Sure. But once again, what "type" would you give this function? Would you
restrict it to integer? Would you allow long integers? What about gmpy.mpz
(another long integer type)?

If you gave me a library with this function in, and it didn't work with
gmpy.mpz values, _simply because you enforced that restriction via a type_, I
would be (justifiably, IMHO) cross.

>Anyhow, this kind of totally polymorphic code is exceedingly rare.

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

Type annotations, as described so far, sound like a sanitised and formalised
version of this:

    def f(n):
        assert type(n) == type(1)

I can imagine *very* few places where an assert like this is of genuine
practical use.

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>

>Type annotations of any type are a known trade-off between raw
>flexibility, safety and error reporting. C++ and ML are way on one end
>of the spectrum. Python is way on the other end. There is a middle
>ground.

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

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

How would you handle this? (Remembering that files are a built-in type, so
saying "files are outside the scope" seems unreasonable).

Paul.