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

Justus Pendleton Justus Pendleton <justus@acm.org>
Fri, 27 Nov 1998 16:48:41 -0500

On Fri, Nov 27, 1998 at 05:52:35PM +0000, Dominic Binks wrote:
> but I have to look up the manual to find out the order of arguments for any
> function I wish to use.  A prototype would save me this.  I know you can
> read the code, but this is not in general a valid answer to the problem.

Hmmm...I'm not sure what the difference between looking up the parameters in
a manual versus looking up the parameters in a prototype are.  Seems like
they are exactly the same thing except that the manual is far more likely to
actually convey some useful information...like what the hell "int *decpt"

> To use an similar example from C:
> struct my_struct {
> 	char *my_string;
> };
> ..
> 	struct my_struct val;
> 	val.my_string = strdup("Hello World!");
> 	free(val.my_string);
> 	printf("%s\n", val.my_string);
> Ok it's not a function, but the basic argument is the same.  Runtime
> ordering of operations cannot obviously be detected by the type system. 
> It isn't there to do that.  It is there to try to assist the programmer
> in detecting areas where they've (inadvertantly) passed the wrong
> argument to a function/method.

I would argue that the above code simply shows that C is broken and nothing
more :-).  The parameter to printf is a STRING_OBJECT, but since C is a hack
it calls it a char * instead.  When you do free on a STRING_OBJECT it is no
longer a STRING_OBJECT.  If I do

x : Int
x = 5
del x

Why isn't x still an Int?

Would a type system catch this error:

def foo(x : String):
x = 'tree'
x = 1

I'm confused about why a type system would catch this but not my original
example...especially if ordering of operations cannot be detected by the type

> A bit of background about what we use Python for.

Thanks, this is exactly the kind of background I was hoping someone would
share to illuminate and educate me ;-)

> Probably about half of that can be placed at easily checkable static
> conditions, type correctness being one of the most important (usually
> because it's often hard to locate).

If Python had some kind of type inferencing engine would it be possible to
have the compiler give a warning at compile time that it looks like you might
be doing something wrong ... without the programmer necessarily having to add
explicit typing information to the code?

Justus Pendleton <justus@acm.org>