[Types-sig] RFC 0.1

[Tim Peters]

[Greg Stein]
> Woo hoo! Tim to the rescue! :-)

Na -- I just like to stir up trouble <wink>.

[Tim code that uses one name for both a dict and that dict's
 list of keys]
> Ha! I posted something just like this just the other day:
>   http://www.python.org/pipermail/types-sig/1999-December/000518.html

Yes, I noticed that at the time but forgot -- it's such a common idiom in my
code that it didn't "stick".

> Basically: I *totally* agree, and this is primarily the time when
> I use a single variable name for two different types. This is also
> a reason why I'd like to avoid the notion of associating a type
> with a [variable] name.

Associating types with names is thoroughly conventional, and thoroughly
appropriate if a given name is in fact intended to have a fixed type -- and
I expect that's most names (e.g., likely every name in __builtin__ and
sys!).

If I have a class with a dozen methods and they all treat e.g. self.x as a
list of floats, I certainly don't want to have to decorate every reference
to and binding of self.x[i] to say that over and over again.  I'd rather use
a distinct name in the few places I "cheat" now.  Heck, given a suitable set
of predefined interfaces, I could declare my dict/list name as being of type
(or implementing the interface) Subscriptable <wink>.  Or of the universal
type (Paul's PyObject).  Although the less specific I am, the less help I
can expect to get from typing -- that's my tradeoff to make.

Given that you *have* to associate types at least with formal argument
names, "avoiding the notion of associating a type with *a* name" is a lost
cause.  A further distinction between "[variable] name"s and "all names"
isn't compelling -- although I hope Guido doesn't listen to me and presses
on with his type inference schemes anyway, because given the types of
globals and arguments, the types of almost all local variables are indeed
easy to infer <wink>.

doesn't-mean-i-want-to-prevent-people-from-declaring-'em-
    though-they're-*used*-to-it-from-other-languages-and-
    there's-no-good-reason-to-outlaw-it-ly y'rs  - tim