Static typing (was Re: Java guy interested in Python)

[Michael Hudson]

Don Dwiggins <dwig at advancedmp.net> writes:

> So, are there any efforts in the Python community to provide
> something in this area?  I'm thinking of things like type inference,
> and of something like "permissive typing" (compiler/interpreter to
> programmer: "you don't have to tell me the type of a variable or
> argument, but if you do, I'll use that information to help you
> wherever I can").

Well, you could try ploughing through the archives of the types-sig.
Python's relentless dynamism makes it hard though, and I don't think
DC have the funds or the expertise the Lisp people did in the
seventies.

There are two sides to static typing, which on the types-sig got
dubbed "OPT" (make things quicker) and "ERR" (better compile-time
error checking), which are somewhat independent.  Oh, and there's
"DOC" (makes the meaning of code clearer) too, which is rather related
to "ERR".

I'm personally more interested in "OPT", but that's certainly not the
only reasonable view.

Also it's not clear that tighter type checking is necessarily a good
thing.  Consider the following function:

def write16(file, int):
    file.write(struct.pack("h",int))

If you type-annotate this, you might write (using entirely made up
syntax):

def write16(file : <file>, int : <int>):
    file.write(struct.pack("h",int))

but then what about passing in a StringIO object, or some user wrapper
of a file object?  What makes a "<file>"?  At the moment, it's just a
loose collection of methods, some of which are optional in some
circumstances.

now-if-you'll-excuse-me-i'm-late-for-lectures-ly y'rs
m.

-- 
  This makes it possible to pass complex object hierarchies to 
  a C coder who thinks computer science has made no worthwhile
  advancements since the invention of the pointer.
                                       -- Gordon McMillan, 30 Jul 1998