does lack of type declarations make Python unsafe?

[Terry Reedy]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:y8HHa.103114$pR3.2238174 at news1.tin.it...
> Terry Reedy wrote:
>    ...
> >> 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').
>
> A 'type' that is checkable at compile-time is (at the very least)
> a set whose membership needs to be fixed and known at compile-time.
> (There may be other requirements, but this one is crucial;-).

I agree completely.

> "The set of acceptable keys/indices into 'blah' at this moment
> (which depends on how big 'blah' is right now, etc etc)" is not
> ``a type'' in this sense.  So, if 'blah' is a std::vector<...>
> in C++, a Vector in Java, a Python list, or basically any sort of
> usable array/vector whose capacity can be determined at runtime,
> then compile-time type checking just cannot substitute for runtime
> checking of indices.

Right.  While my statement about counts and residue classes is
correct, it is not as applicable to indexes of variable-length
whatevers as the juxtaposition implied.

My point about counts is that if we are going to type things (as the
OP advocated, perhaps like C/C++ do), then len(whatever) is better
typed as returning a count rather than an int.  At least I would claim
so if the language has exceptions and doesn't 'count' on being able to
return impossible negative lengths as error indicators.  If, as in
C/C++, negative indexes are not allowed, then indexes are also better
typed as counts rather than ints.  But checking upper bounds is more
complicated, even for fixed length arrays.

Terry J. Reedy