[Types-sig] recursive types, type safety, and flow analysis (was: Recursive types)

[Paul Prescod]

Guido van Rossum wrote:
> 
> Hm...  Since type checking is essentially a compile time activity, I
> think it would be better if the run time order of events didn't
> matter.  

I agree.

> > I haven't thought about this particular scenario or the resulting impact
> > on the inferencer.
> ...
> I don't see a big problem here for the type checker.  

The problem is that you and I are thinking about a Algol-style type
checker. Greg is talking about a complex, sophisticated type inferencer
that tries to understand what your Python code *means*. I am only
willing to try to understand Python in the very simplest cases: top
level definitions that have no dependence on procedural code.

> I like the idea better (I think proposed by Tim Peters) that the names
> used for type declarations live in a separate compile time namespace
> where different rules apply.  (Even though there are obvious
> correspondences, e.g. the names of defined or imported classes should
> probably be available both at compile time and at run time.)

I agree. We will soon have to move forward on this basis.

The static type checker is a very different tool and it does not, in
general, try to understand "Python code." Two *convenient exceptions*
are top-level class and function declarations. But these are just
convenient exceptions. I feel strongly that this:

if doSomething():
	class a:
		def doSomething(self):
			pass
else:
	class a:
		def doSomething(self):
			pass

is NOT TYPE CHECKABLE because we do NOT do data-flow analysis.

 Paul Prescod