[Types-sig] Issue: binding assertions

[Paul Prescod]

Okay, we need to move to conclusion on certain issues so I can make a
new RFC. A week ago I posted a proposal that had a concept called
"binding assertion":

#2. The system must allow authors to make assertions about the sorts 
of values that may be bound to names. These are called binding
assertions. They should behave as if an assertion statement was
inserted after every assignment to that name program-wide.

Greg argued relatively persuasively that it was more Pythonic to allow
the same variable to have varying values over time. This is great in the
local case but causes problems in cases like this:

def brian(a) -> int:
	a.spam=42
	somefunc( a )
	return a.spam+a.parrot

Without getting into nightmares of "const" and so forth, we need to deal
with the fact that we can't know the type of a.spam and a.parrot without
analyzing somefunc and maybe other code. We don't have that option.
Therefore we must be able to guarantee at least the type, if not the
values, of a.parrot and a.spam. 

Now if a is a module object then hard-coding the values is equivalent to
declaring the static, unchanging type of global variables. So in at
least the module and class instance cases, we are binding types to
names, not values. This begs the question: is there any reason to treat
parameters differently and allow parameters to vary over their lifetime?
And what about declared local variables? Surely they must behave the
same as global variables!

My personal vote is that we treat all variables the same. Someone who
wants to allow some particular name to vary its type over its lifetime
has the following options:

 * turn off type checking
 * declare it to be of type Any
 * declare it to be of type dict | list of string

If we are too strict at first then we could ease the rule based on
feedback. I *do* understand that the vast majority of local variables
(not parameters) should have their types inferred (perhaps just as
"Any") rather than declared.
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things see no end: A loop with exit code done wrong
A semaphore untested, and the change that comes along
http://www.geezjan.org/humor/computers/threes.html