Adding static typing to Python

Chris Gonnerman chris.gonnerman at newcenturycomputers.net
Tue Feb 19 09:03:14 EST 2002


I've tried to think of a way to articulate this... but I am not
getting very far.

When I wrote mostly C, I spent a lot of time engineering library-
like functions, usually in several layers, carefully hiding data
as much as possible.  Often I had to resort to globals to cut
development time; then I regretted it later.  Simple things like
string manipulation required a lot of extra variable declarations,
checks for overruns, etc. which naturally made the code difficult
to read.

Sure, I commented, chose obvious variable names, and I tended to
segment my code into "operation"-sized units, but still, getting
an overall view of a function (or module, for that matter) was 
far from trivial.  Bugs hid in there.  I have recently been running
one of my old C programs from about ten years back, which I had
believed mostly bug-free; the many bugs I am finding are surprising.

Now most of my work is in Python.  It's true, most of my programs
are small anymore; I rarely *need* to write large programs.  One 
line in Python often equals three or more in C, and more often than
that, two or three lines replace ten to twenty lines of C.  I get
my work done, without static typing, typechecks, or assertions
(once in a while I do use an assertion...)  They *just work*, and
when they don't it's REAL obvious how I've been stupid.

Python is *readable*.  I have yet to see any proposal for static
typing that improves on that; and as I have said before, with
static typing it's not Python anymore.  Design by contract 
implemented for Python would have to be pragmatic (i.e. by
"suggestion" rather than "mandate").  

Python isn't about tying the programmer's hands, it's about freeing 
his or her mind.







More information about the Python-list mailing list