[Types-sig] Why I don't like static types in Python
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
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
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.