Static Typing in Python

[Jacek Generowicz]

On 13 Mar 2004, at 08:07, Premshree Pillai wrote:

> Yes, I am aware that Python is dynamically typed, and
> so is Perl, right? In Perl, we have the "use strict
> vars" pragma to force variable declaration.

I'm no Perler ... but by reading a bit of documentation, I get the
impression that you are a bit confused about what "use strict 'vars'"
really does. It seems to be some mish-mash of concepts: it imposes the
necessity to fully qualify names, to declare (the existence, not the
type of) variables with "our", and does some control of scoping rules.


Whatever it does, it seems that "use strict 'vars'" has absolutely
nothing to do with static typing.


So, I must ask you the same question as I asked Peter: "what do you
understand 'static typing' to mean?"


> Is there something like it in Python?

No.

> Don't you think forced variable declaration is an
> important requirement in a language?

No. Absolutely not. I think that an important requirement in a
language is that it NOT *force* variable declaration. (Optional
declaration is fine.)


I do think that it is an important requirement in a language that test
suites be easily written in it. I also think that it is an important
requirement of developers that they write comprehensive test suites as
they develop their software. The test suites will catch ALL SORTS of
errors (including those resulting from type errors). Static type
systems, OTOH, catch only one, minor, class of errors (type errors),
and do so at great cost.


Static typing catches even those type "errors" which would in no way
prevent the program from running correctly. (Implicit static typing
systems are much better in this respect than manifest ones.)


Static typing makes the language more inflexible, and makes it much
more difficult to run incomplete programs. Why would I want to run an
incomplete program? Well, during the *whole* development phase, a
program is incomplete. Just think about that for a minute. And I would
certainly like to run my programs during development to test them.


Your average C++ programmer is so happy when the compiler eventually
complies his program without errors (even though it may signal 300
warnings), that he is convinced that the program is correct. "I
Suffered so much, and fixed so many errors to get this far. If the
compiler, which is so pedantic and spotted all those errors, can't
spot any more, then surely there _aren't_ any more errors in my
program." And he thinks he has finished. He hasn't been able to run
any tests so far (this is the first time that the program has
complied), so the program is almost guaranteed to be bug-infested, but
the thought of writing a test-suite at this point (if it would cross
his mind - it won't; the complier has already told him that his
program is error-free) would be so frightening that he would quickly
dismiss it. If, however, he did try to write a test suite, then the
third bug he'd find, would motivate him to make a tiny change which
would make the static typing system reject his _whole_ program. He
would then notice that the static type system forces a whole chain of
changes upon him, extending into parts of the program which are in no
way related to the part which he is actually trying to test, before
allowing him to run the program again, in order to check that his fix
works. That chain of changes would, of course, set off new chains of
changes along its way, and those chains ... you get the picture.


I think that manifest static typing systems are great way of slowing
down development, and ensuring less (sic) correct programs.


Variable declarations are usually just noise, which obfuscate the
program, and make it a pain to write.