[Types-sig] Why I don't like static types in Python

Gordon McMillan gmcm@hypernet.com
Fri, 27 Nov 1998 13:40:39 -0500

Justus Pendleton wrote:
> On Fri, Nov 27, 1998 at 10:21:40AM +0100, Fredrik Lundh wrote:
> > Hmm.  Based on what's said on http://www.python.org/sigs/types-sig/


> When I click on the link for "Static Typing Proposals" it says
> "coming soon". When I click on the link for "Interface definitions"
> it says "coming soon".

The summaries are now there:

> My response was based on reading Roger Masse's current position
> paper, "Add Later Static Types for Python" and his summary of the
> developer day session on the same topic.
> As far as I can tell this is a working group for "discussions on
> issues related to Python's type system" and I think that before
> anyone starts discussing how to implement static types it might be
> good if it were clear what the goal of such a system might be.  I
> couldn't find a clear description of that goal in anything that I
> read.  My post was an attempt to clear up what that goal might be.

Unfortunately, there are nearly as many goals as there are interested 
developers. And some of those goals are "to see if turns into 
something interesting", which is damned hard to quantify.

One of my (stated) goals is to make sure nothing undesirable gets 
rammed down my throat. You could assist in that regard, but not by 
saying that people shouldn't be interested, or shouldn't be playing 
with possible implementations.

> > But in a world where all larger programs are dynamically configured, global
> > analysis is a relatively worthless concept.

Now Fredrik, it's not worthless (or even "relatively worthless"), 
just of limited applicability. And you can certainly learn things 
from the exercise that might help with local program analysis.

> Out of curiosity (since I don't know) does this mean that run-time
> and/or dynamic recompilation are equally fruitless avenues of
> inquiry?

They're a lot harder. For one thing, you have to optimize the 
> > We're not talking 10% speed increase. We're talking near-C speed.
> > And from another perspective, much lower development costs for
> > equivalent code.
> I admit that I am skeptical of claims of near-C speed :-)  Java is
> statically typed and isn't really "near-C speed".  Python claims to
> be a higher level language than Java so I have difficulty believing
> it will succeed where Java fails....especially since Python's static
> typing would be voluntary which makes me believe that it wouldn't be
> as effective as Java's mandatory static typing.

Jim Hugunin used global program analysis to demonstrate (admittedly 
contrived examples of) JPythonc compiled code running 2000X faster 
than CPython. In the example, his analysis was able to arrive at the 
conclusion that a Python Int could actually be compiled to the Java 
for a native int.

> I have a question (since I don't know), if the static typing is
> voluntary then does that mean that nothing in the core python
> library could use static typing?

Python 1.6 is intended to be as backward compatible as possible. 
Whatever pieces of these 3 topics show up in 1.6  should be safely 
ignorable if that's what you want.

Python 2.0 (a long way off) is another story.

> Hmmm...this doesn't really answer my concern about the lack of
> empirical evidence of the usefulness of static typing.  Anecdotal
> evidence simply isn't enough as far as I'm concerned.  For years
> there was anecdotal evidence that client/server systems were the
> brilliant wave of the future, but in the November/December issue of
> IEEE Software Diomidis Spinelli argues convincingly that
> client/server systems have failed.

I'm not aware of any empirical evidence saying that empirical 
evidence should be a prerequisite for exploring new language 
features.  On the contrary, there is empirical evidence that 
empirical evidence can be found for pretty much any conclusion 
desired. Without having read it, I would be tempted to site your 
citation as an example <wink>.

Just go through any out-of-date papers from any scientific 
discipline. There are plenty of examples of studies with empirical 
evidence that today are completely discredited.

Pick up Against Method by Paul K. Feyerabend.

> > >Maybe if someone could give me an example of a real world problem
> > >they couldn't solve in Python because it lacked these features it would
> > >be easier for me to understand the need we are trying to address here.

Very rarely is anything about "couldn't". It's about making it easier 
or more natural or faster.

I think if you want to see where Jim Fulton and the "interfaces" 
proposal is coming from, you should look at Bobo, where he uses 
introspection heavily so that the user can write very natural Python, 
but Bobo can determine what is "safe" to publish as CGI.

There's plenty of empirical evidence that Python is "slow", which is 
constantly thrown in our faces, despite the fact that it is usually 
very misleading.

It's also quite clear that static typing can prevent a kind of error 
that is very difficult to prove absent in a dynamic system. Whether 
it's worthwhile is another question, and one that really isn't 
answered for Python by looking at other languages.

Unfortunately, it looks like the type / class thing can't be resolved 
until Python 2. But I'd be surprised if anyone asked for empirical 
evidence that this is a flaw in the language.

- Gordon