Understanding Modern Python

Originally a dynamic (strongly) typed OO language.

It is an OO language in the first place (all advanced features are based on classes and objects).

It is an imperative language, with functional-style immutable bindings and proper aliasing of values but also with destructive assignments (overwrites) and imperative loops.

Now it comes with type-hints syntax (annotations) and type checking.

It is still a dynamically-typed language, which means that type-hints and type checking are optional (not required, do not necessarily cause compile-type errors).

3.11 added optional initialization syntax for typed values, so it feels like a new, typed (type-annotated) language.

Notice that modern Python (as of 3.11) is not the simple studying language you may encounter at a university or in an old book.

Nowadays it has an iterator /comprehensions, even a rudimentary pattern-matching expressions, and embedded DSLs like f-strings.

The huge and hyperactive online community is piling up features (not necessarily the right ones – notably the async crap) at an astonishing speed.

Advanced typing (based on type-constraints, type-classes, etc), however, is always good, no matter the “costs”.

It requires, however, ever more learning, and the right understanding for not to misuse and not to over-abstract.

The type-checking (of type-hints, which is just a valid syntax) is implemented as ordinary modules and the interpreter just call them at an appropriate time.

Actual objects are structurally annotated (or decorated) with attributes, which store the type information. This is still a dynamically-typed language, after all.

There are already whole “frameworks” which manage “decorated” type-information at runtime, like pydantic. Notice that all this is just an ordinary python code (in modules), which “deals” with type-hints, not some part of the “compiler”.

There is a compiler, and the compilation phase in Python, but it does not have a static-typing discipline (a type of every expression or a value must be known and checked at the compile-time), and it does not erase the type information (it is structurally available at runtime).

Adding a type-information stricturally right to the objects is a “classic” choice. Early languages just attached (cons-ed) type-tags to values.

The whole approach of just adding more “meta-data” structure to actual objects is OK