[Types-sig] Re: Inferencing: A case study

[Paul Prescod]

Guido van Rossum wrote:
> 
> > I spoke to the Journal of Functional Programmers at a conference
> > recently.
> 
> Is Journal some kind of military term, maybe between General and
> Sergeant? :-)

I spoke with an editor of said Journal. :)

> I agree.  Typically, especially for libraries, there should be type
> decls at the module boundaries to avoid endless "exercises for the
> reader" as in my case study.  (Note that the case study actually
> stipulates that the re module has a module declaration, and explains
> why.)

Good, we are in agreement. 

I've been thinking: I can allow statically checked references to
type-inferenced module variables if we make the module namespace
write-only outside of the module. The "trick" is that I need to put a
boundary around where I expect writes to take place so I can check that
I can figure the complete list of possible values the variable can take.
If writes can come from outer space then I need to check every write at
runtime.

So, I can do static type checking on a module variable if:

 * it is declared only "privately writeable"
 * or the whole module namespace is "privately writeable"
 * or it has a type declaration.

We can provide access to any combination of these options that we
decide. 

Privately writable is more pythonic than "const" which was my first
reaction. Of course the vast, vast majority of module variables are
privately writable. And one could argue that ALL of them should be.
Module namespace writability is a security nightmare and it is SO easy
to move writeable variables to an object:

sys.path => sys.runtime.path
sys.version => sys.impl.version
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
Three things to be wary of: A new kid in his prime
A man who knows the answers, and code that runs first time
http://www.geezjan.org/humor/computers/threes.html