does lack of type declarations make Python unsafe?

[Terry Reedy]

beliavsky at aol.com wrote:
> >> Calling functions with invalid arguments is one of the commonest
> >> programming errors

> Peter Hansen wrote:
> > Debatable.  Not true in my experience.

"Alex Martelli" <aleax at aleax.it> wrote in message > > > Pretty true in
my own experience, for a suitably generalized definition
> of "functions" that includes operators and other callables.
However,
> the reasons the arguments are "invalid" are more often connected to
the
> *values* that those arguments take at runtime, rather than to the
types
> of those arguments (which might be checkable at compile time if one
> used a statically-typed language), therefore this is not an argument
> in favour of static type-checking.

If one considers the set of values as part of the type, this amounts
to saying that the type system of most languages is too coarse for
real needs.  Many operations need counts [0, 1, 2, ...].  Python does
not have this, C only backhandedly (unsigned int, like calling an int
an unfractionated rational).  A few need a count subset: circular
queues need residue classes [0, 1, ..., n-1] with all operation
results taken %n.  These are well-defined mathematical sets that
programmers usually have to simulate rather than simply declare.

Similarly, absolute measurements (as opposed to differences of
absolute measurements, like deviation from freezing temp and sea
level) and the input to real/float sqrt() and other functions are
'non-negative floats'.  I don't know of any language that lets a
programmer directly declare this type.  C lets you typedef structures
but not restricted subsets.

> E.g., indexing blah[bloh] with an
> invalid index value computed in variable bloh (invalid with respect
> to the set of indices that container blah can accept) is, alas, far
> from rare; but it's not a type-checking issue,

Depends on what you call a type.  A 'count' or a 'residue_class' is as
much a mathematical 'type' as an 'int' (or a 'rat').

Terry J. Reedy