[Types-sig] Recursive types (was: Basic questions)

Guido van Rossum guido@CNRI.Reston.VA.US
Tue, 21 Dec 1999 15:42:33 -0500


> From: Greg Stein <gstein@lyra.org>
> 
> On Tue, 21 Dec 1999, skaller wrote:
> >...
> > 	If I may: there is an issue here which
> > some people may not have realised: recursive types.
> 
> These are not possible in Python because definitions are actually
> constructed at runtime. The particular name/object must be available at
> that point in the execution.

Huh?  "Recursive types" typically refers to all sorts of nodes, graphs
and trees (where an instance attribute has the same type as its
container).  Certainly these are possible in Python!

> > In an interface file, this can be handled by 
> > two passes.
> > 
> > 	In implementation files, it is much
> > harder, since scoping rules are dynamic.
> > This is a good argument for interface files.
> > Example:
> > 
> > 	class X:
> > 		def f(y:Y): ...
> 
> This fails. Y is not defined.

If I understand the context correctly (X defined before Y but using Y)
I disagree.  Since this works fine without type declarations (as long
as the instantiations happen after the classes are defined) I don't
see why adding static typing should break this.

Also, I think that static typing should have a much more liberal view
about forward referencing than Python itself.  Since it is quite legal
to have

  def f(): g()
  def g(): ...
  print f()

I think that typecheckers should deal with this, and not complain
about the forward reference to g in f!  (Except when f is called
before g is defined.  Flow analysis should allow this distinction.)
(Incidentally, this is one of the things that annoys me about Aaron
Watters's kjpylint: it warns about all forward references.  This
conflicts with the top-down coding style that I currently prefer for
procedural coding, where main() precedes everything it calls, and so
on.)

--Guido van Rossum (home page: http://www.python.org/~guido/)