does lack of type declarations make Python unsafe?

[Anton Vredegoor]

Alex Martelli <aleax at aleax.it> wrote:

<snip links with conditional appreciation of strong dynamic typing>

>Note the commonality: "unit tests", "strong testing".  Halfways decent
>unit-tests will catch all the type-errors that a typical statically-typed
>language would catch *and then some*.  Without unit-tests your code is
>untrustworthy anyway (both Robert and Bruce make the point forcefully!),
>while, WITH good unit-tests, type issues "simply never arise" as Robert
>Martin puts it.
>
>BTW, I strongly recommend Kent Beck's "Test-Driven Development by Example"
>(Addison-Wesley) -- short and to the point.

Seems everyone is trying to kidnap the baby, smothering it in True
love and imprinting one's personal worldview on it, justified by
rightful concerns about its security :-)

Let's have my view on it then, too. In my opinion the obsession with
testing is a left over from the time one was concerned with type
checking. It is as if one is not really ready to enter the world of
signature based polymorphism, so one seeks the aid of different kinds
of crutches, not realizing that these too, in the end, will prove to
be just as much of a hindrance.

Further more, this seems to be intimately related to the excessive
insisting on use cases before one is ready to accept new features. For
example, what was the use case of the first car? There where no roads
then, nor gas stations, and the things where really not very useful
compared to proven, age-old methods of transportation. However, given
that the necessary infrastructure is present, things can be done with
them that one never could do with horse and wagon, things that one
never even thought about doing. (By the way, I do not own such a
monstrosity.)

What's the use of replacing type checking with batteries of tests
while the real advantage of coding in Python is its "executable pseudo
code" character: "Look ma, no testing necessary!" How can we achieve
that? As usual, by providing the infrastructure for this general idea
to work. PyChecker is a great tool, but also usenet and peer review.
Having one's code checked by hundreds of people reviewing it, for
example by posting it on a public platform, makes the most of the
"eyeball ready" advantages of languages like Python.

I think a lot of programming strategies claim advantages that are
really not caused by them but are caused by the inviting and enticing
properties of the language itself. Python lends itself to playing with
it and to discussing the merits of code snippets with other people.
It's one of the "language" languages, in that it's suitable for people
to communicate using it, and it can even be used as tool to check ones
thoughts.

Now to go back to test driven development, is it necessary to
formulate a plan first before springing into action? As logical as it
seems this is again just a relic of the old static typing fears. Any
linguistic expert - and I'm now using the term in a more psychological
way - will tell you that speech production is "on the fly". This means
we do *not* know what we are going to say before we speak - not even
Dijkstra - , the specific regions in the brain just produce the
linguistic output that corresponds to the things we want to say in a
way that we do not directly control. How could we, given that it's a
real time process? The same should go for a computer language, type in
your thoughts (or speak!) and let the computer figure out how to best
express it! Use a user platform to test the effect of your utterances
or correct them using "live" feedback from the interpreter.

Python is not there yet, but a failure to notice the transformation of
computer languages into languages of thought, and relying on excessive
backtracking of all utterances, instead of concentrating on the
content of what is to be expressed, is a sin against that what is yet
to come.

Anton