Exactly right, great example. And furthermore:

    >>> foo: int = 'hello'
    >>> type(foo)
    <class 'str'>

Python's type annotations are annotations. Types are being enforced at runtime, it's just that some are thinking that annotations have some effect on the interpreter, when they do not.

This is a demonstration that it has not enforced what many would reasonably believe is a static type declaration.

But we have (to quote another commenter) "uneducated" people making a supposedly boneheaded mistake to assume

    x: T = y

is a declaration that x will only contain values of type T, or otherwise something will be detected by cpython as invalid (at either bytecode-compile-time or run-time).

Instead, this line is more properly interpreted as "documentation reasonably believed to represent a type saying something about values that x can be assigned at runtime, that's not in a docstring, that some programs may query."

I can totally forgive anybody who believes the former over the latter, and expresses their belief in a statement like that which you've quoted.

Type hints are not static type declarations. Python does not refer to them as such, nor does Mypy or any other typechecker for Python type hints.

Absent of active machine checking (e.g., via mypy), type hints should be considered exactly what you said: another form of documentation, one that might just be wrong.

This is my point precisely: it looks like a static type declaration to anybody who has seen what a static type declaration looks like in any statically or gradually typed program in the last 50 years.

But in Python, it's not (and documented in a PEP as not), and it causes massive confusion.

That's the way it works in Ruby with RBS, and it will work the same way in JavaScript should Microsoft's proposal for type hints make it into ECMAScript[1].

[1] https://devblogs.microsoft.com/typescript/a-proposal-for-typ...

Yeah, you are talking about actual types and not type hints. It gets confusing. Python doesn't enforce type hints at runtime.