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.