"no variable or argument declarations are necessary."

Paul Rubin http
Thu Oct 6 15:55:45 EDT 2005


Mike Meyer <mwm at mired.org> writes:
> I think we're using different definitions of statically typed
> here. A language that is statically typed doesn't *need* type
> inferencing - the types are all declared! Type determines the thypes
> by inferenceing them from an examination of the program. 

I thought static typing simply means the compiler knows the types of
all the expressions (whether through declarations or inference) so it
can do type checking at compile time:

> So, for instance, it can determine that this function:
> 
> def foo():
>     return 1
> 
> Won't ever return anything but an integer.

Static typing in this case would mean that re.match('a.*b$', foo())
would get a compile time error, not a runtime error, since re.match
expects two string arguments.  This can happen through type inference
w/o declarations.

Note apropos the private variable discussion that CPython can't
guarantee that foo() always returns an integer.  Something might
change foo.func_code.co_code or something like that.

> Maybe you're still writing code for a language with declerations? I
> never felt that need. Then again, I came to Python from a language
> that didn't require declerations: Scheme.

I've done a fair amount of Lisp programming and have found the lack of
compile-time type checking to cause about the same nuisance as in
Python.  I also notice that the successors to the old-time Lisp/Scheme
communities seem to now be using languages like Haskell.

> > Well, in the end, I would really like an *option* at the beginning of a
> > module file requiring variable declaration for the module. It would
> > satisfy both the ones who want and the ones who don't want that ...
> 
> Nope. It would just change the argument from "Python should have ..."
> to "You should always use ..." or "Module foo should use ...".

Perl has a feature like that right now, and it doesn't lead to many such
arguments.



More information about the Python-list mailing list