I'm not sure if you're being serious, but Im going to assume you are.

Your first example demonstrates that python does not have compile time type checking

Your second example demonstrates that python variables can dynamically change types.

  >>> 1 + "2"
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unsupported operand type(s) for +: 'int' and 'str'

https://dev.to/jiangh/type-systems-dynamic-versus-static-str...

What that article calls "dynamically typed" is commonly referred to as "untyped" in PL research.

The program '1 + "2"' is a perfectly valid python program with well defined behavior (it signals a TypeError). This demonstrates that you can in fact add integers to strings in python. Of course whether or not you can add integers to strings is completely orthogonal to whether or not a language is typed. Both typed and untyped languages may overload the addition operator.

For those downvoting aidenn0's comments, I was surprised to find that "untyped" is indeed a common term that includes what many people (myself included) call dynamically typed. See the three top-voted answers to this Stack Overflow question, one of which includes a citation from TaPL, a standard text (emphasis added):

"A type system is a tractable syntactic method ... Terms like 'dynamically typed' are arguably misnomers."

https://stackoverflow.com/questions/9154388/does-untyped-als...

I still prefer the term dynamically typed, because there are useful distinctions about value types to be made among such languages, such as those described in striking's link.

I think this discussion is frustrating because your explanation seems to be based on well-defined terms of art, as opposed to the colloquial terms like "weak" and "dynamic".

It's like the discussion is untyped, and the downvotes are runtime errors that would have been caught if terms were agreed upon ahead of time.