[Types-sig] Static typing considered HARD

[Uche Ogbuji]

Martijn Faassen wrote:
> My take on static types in Python has been the Swallow proposal. The idea
> is that we want some early-result points in the project to add static
> types to Python. With quite a few others I deem the possible speed payoff
> of adding static types as least as important as the possible code-quality
> payoff.
> 
> Adding static types to Python proper is hard, and undesirable if it entails
> giving up too much of Python's dynamicism, as has been observed.
> 
> The assumption of Swallow is that many parts of a typical Python program
> do not profit a lot from Python's dynamic typing, though of course other
> parts do. Traditionally the only way to gain speed with Python programs
> has been to move parts that can be static anyway to C. This is however a
> rather big step. It would be nicer if our extension modules could be more
> like Python itself. This way there is a gradual transition between
> dynamic Python to static Python code.
> 
> The Swallow proposal is to find a subset of Python (Swallow) that is
> horrible in all the ways Uche so empathically dislikes. :) Get rid of
> whatever is necessary in Python to make Swallow amenable to static types;
> restrict imports to the top, restrict what magic one can do with classes,
> etc. The important point is that Swallow is a strict subset of Python,
> not adding any facilities or different semantics of its own, as much as
> possible.

I actually don't have too much problem with this approach.  I don't like
to entirely shun the voices that clamor for dynamic typing: my main
concern is that such mechanisms are entirely optional and transparent to
those who don't want them.

Your discussion of optimization exactly meets my experience.  When we
run into speed problems, we find a part of the 20% of the code that is
really doing all the work, and we re-write it in C.  An open-source
example is in 4XSLT, which at first did all the Path expression parsing
in Python.  We found that this was having far too heavy an effect on
performance and re-wrote it mostly in C.  If there were a way to take
_only those sections to be optimized_ and instead re-write them in a
Pythonic syntax that could then be compiled to bare-metal speeds, I
would appreciate it and use it as much as anyone else.  I wouldn't
expect or desire such a facility in the language core, however.

The type-safety issue is entirely different, and IMHO this is where the
real fantasy comes in: people thinking that statically-typed languages
are really less susceptible to semantic errors than Python. 
Nevertheless some _very_ smart people here say that static typing will
solve their code-quality problems, so I say, why can't we deal with this
using a separate static-type-checker, maybe with some
interface-definition language embedded in DocStrings or a separate spec
file?  Of course this doesn't address the problem of dynamic
type-modification, but if that's so scary, why use Python?


-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org