Re: static type checking / interface definitions for Python?

Steven D. Majewski (sdm7g@virginia.edu)
Fri, 23 Sep 1994 12:39:14 -0400 (EDT)

Glad to see this subject come up again.

I suggested some time ago that we reserve the syntax for static
declarations in Python. I wasn't sure quite how we would implement
them, and that, at least initially, we might want to experiment
with something outside of the compiler/interpreter. I was
thinking along the lines of a sort of Python-lint, but using
ML ( or ABC ? ) style type inference. I wasn't quite sure how
to DO it all yet, but I suggested that we define and reserve
a syntax for declarations, and make them legal but no-ops in
the current implementation, so that we could experiment with
implementations. My suggested syntax was pretty close to
what Bill suggested, also. But nobody was very enthusiastic
about the idea at the time. :-(

In fact, the non-positive response I got on that ( along with
the lack of time to learn how to implement a type inference
system! ) was one motivation for my more recent suggestion.

[ At the time, Guido and the list were in more of a "What is
this good for?" anti-featurism mood, and I just didn't have
the time to do all the homework to answer all of the questions.
Clearly, a couple of contradictory directions for an implementation
suggest themselves - depending on whether you are considering
declarations as a type-checking safety feature ( with or without
type inference ) or as a Common-Lisp like feature to produce
optimized, but specialized code. Ever since the ancient days
of the "Overly Pedantic Type Checking" thread, I've been wary
of things that might over-specify ( and thus under-generalize )
the code. So maybe code optimization is better done by more
dynamic (ala. Self) specialization. ]

Guido had an initial stab at an attempt at a python to
C translator. I assume the intent was that one could prototype
in Python and then take working and tested Python modules
and translate them into C ( with generous help from the
python runtime support libs ) and compile the C into loadable
object modules.

I don't know how far from useful that Python-to-C code was,
but I asked whether it might not be easier to map Python to
Modula-3. My impression was that, *except* for the declarations
and the static/dynamic distinctions, Modula-3 and Python aren't
that different. ( I've only read, not written any Modula-3 code,
so I may be underestimating the differences) However, I've since
gotten stalled by being unable to get the Modula3 library to
compile on AIX ( and I haven't had the time to figure out the
problem yet. )

Obviously, a Python-to-Modula3 compiler would also find optional
Python declarations useful.

-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cheese is more macho?" ]