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

Fredrik Lundh fredrik@pythonware.com
Sun, 29 Nov 1998 22:27:12 +0100

>Hmmm...the page I read said
>"This list has been created for discussions on issues related to Python's
>type system."

Sure, and then it outlines the three main subjects for this
working group:

-- interface definitions

(which according to the text on that page would allow programmers
to "test object behaviour", provide "a basis for analysis of type safety",
and improve the "organization to library and extension classes".  ok?).

(note: "implicit" interfaces are already used in this fashion in the
Python universe -- you've probably seen terms like "sequence", "file
iterators", "callables" etc.  This attempts to formalize this, so you
can at least use "assert" to verify that your function has been given
a valid argument...)

-- classes vs. types dichotomy

(this aims to remove what is essentially a CPython implementation
quirk.  JPython already does this right.  still with me?)

-- optional static typing

(more on this below).

>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.

Wrt "static typing", the page I pointed you to still says:

    "In order to better support a wider range of solution domains, [1]
    in support of building systems in-the-large with Python [2], and to
    improve performance [3], there is some interest in developing an
    optional static typing system for Python. [4]"

I didn't write that page, but here's my interpretation of those four

1) make it feasible to use Python for more software engineering tasks

2) make it easier to use Python in large, multiprogrammer projects, by
adding run-time support for type/interface testing

3) do I have to explain this?  alright, here's an illustration:

C:\>erase histogram.*
C:\>copy src\histogram.py .
C:\>python testhisto.py
16.6440000534 seconds
C:\>erase histogram.*
C:\>spy2c -mq src\histogram.py
SPY2C (c) Secret Labs AB 1997-98
histogram.dll ok
C:\>python testhisto.py
0.0200001001358 seconds
C:\>python testhisto2.py
0.0199999809265 seconds

(where testhisto.py uses a function in histogram.py, and
testhisto2.py uses PIL).

4) people are already working on this, so there's obviously some
interest.  people also see the possibility to save a lot of time and
money by being able to prototype in Python, before adding what-
ever optional information you might need to translate the result
to C or machine code.

> My post was an attempt to clear up what that goal might be.

You actually responded to a post which had nothing to do with
static typing.  Methinks you're still mixing the three issues.

>Perhaps some of these "many highly experienced Python developers" could
>answer my questions without resorting to the Authority or Social Proof
>methods of persuasion?

I still claim that you'll find those answers on the page I keep
pointing you to (the page was written after the conference).
If you don't, please tell me which parts you find unclear.

>I don't care how experienced the doctor is, I usual prefer an
>explanation of why he needs to conduct a rectal examination....

Well, some of your arguments have been pretty much like "since
I don't need to see my doctor right now, I don't think we need to
have doctors at all".

>> But in a world where all larger programs are dynamically configured, global
>> analysis is a relatively worthless concept.
>Out of curiosity (since I don't know) does this mean that run-time and/or
>dynamic recompilation are equally fruitless avenues of inquiry?

Why does one thing automatically have to exclude another?

>> 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 :-)

See above.

>Java is statically typed and isn't really "near-C speed".

It is, if you compare apples with apples -- that is, take a
typical Python C extension and rewrite it in Java, and then
compile it with a Java2C compiler.

(The really interesting issue here isn't replacing applications
written entirely in portable assembler with Python, but to
replace applications written in Python+C with applications
written entirely in Python).

>Python claim 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.

You mean, like "hey, we don't need doctors since they
 cannot cure people who don't bother to visit them" ?

(I repeat: if you don't like static typing, why not ignore the
whole thing?  despite all talk about Guido's time machine,
nobody's going to use that to add mandatory static typing
to the Python interpreter you're using today).

>Maybe if someone had a working example of a statically typed,
>dynamic, higher level, object oriented language that has near-C
>speed I would be more easily convinced..?

Why does it have to be everything at once to be useful?  I'm
playing with statically typed, statically compiled, medium level,
procedural Python, which actually happens to be exactly as fast
as corresponding C code in most cases.

>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.

If we're talking static typing + static compilation, the entire
Python interpreter could be written in Python...

>> >Roger Masse writes that static typing provides an 'improved level of type
>> >safety and program correctness' but I'm not aware of any empirical evidence
>> >of this. 
>> How large is your largest Python application?  10k lines?  20k lines?
>> 50k lines?  How many people worked on your development team?
>> How many design iterations have you had this far?
>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.

I don't have enough academical background to tell the difference
between "anecdotical evidence based on studying lots of large
real life projects" and "empirical evidence", so I have to pass on
this one.

>> >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.
>> http://www.python.org/sigs/types-sig/
>I am subscribed to the list and have read every message that has ever been
>posted to the list (all 54 of them :)

Not the mailing list, the page itself.  It's all there.

>Virtually all of them are about interfaces.  Virtually all of them are about
>implementation.  If you could actually point out which one of those 54
>messages contain "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."

If you're still talking static typing, the answer is "anything for
which performance is critical".  If you need examples, just look
at the most popular C extensions, and why people keep using

Cheers /F