Mike Meyer <[EMAIL PROTECTED]> 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.
--
http://mail.python.org/mailman/listinfo/python-list
