"Compile time" checking?

[Guest]

Since Python does not use manifest typing, there's not much you can do about
this, but typeless languages like this are great if you're using a process
that finds the errors the compiler would otherwise find. I'm referring, of
course, to Test Driven Development (TDD).

If you do TDD, you won't miss compile-time checking much. In fact, the extra
kruft that manifest typing requires is an annoying burden when doing TDD, so
Python is a breath of fresh air in this regard.

What test should one implement to catch that kind of errors like in OP
example?

 

[Steve Jorgensen]

What test should one implement to catch that kind of errors like in OP
example?

None - other tests you would write would fail if other code in your system is
trying to call a procedure with the wrong number of parameters.

 

[Benjamin Niemann]

What test should one implement to catch that kind of errors like in OP
example?

A 'good' testsuite should run each line of the code at least once. There's
more to do for a good code coverage, but that's the most basic requirement.
So the faulty line will be executed by the testsuite and the runtime
checking will raise an exception.

Static typing is a very rudimentary type of code checking that is performed
by the compiler with 100% code coverage. Such test won't tell you, if your
code is actually doing what it is supposed to do (or anything sensible at
all) and are mostly useless. If you think that code quality is important,
you'll have to perform much more and more sophisticated tests. Such a
testsuite is usually (I can't think of cases where it is not) a superset of
static code checking - all type bugs are found be the testsuite even in the
absence if static type checking.

So you won't loose anything, if you drop static typing.