(Evil interpretation: this is an effort by Python's little tin god to sabotage PyPy. Type information is a huge win for a compiler; it can now generate hard code for a specific type. It doesn't help CPython much, since inside CPython everything is a CObject. With type information, one could write things like NumPy, with its arrays of uniform type and functions which operate on them, in Python. The PyPy compiler could then generate efficient code for them. This would make PyPy the primary Python compiler. But if type annotation isn't enforced in CPython, code won't port reliably to a compiler which enforces it.)
``` foos = [Foo(a=0), Foo(a=1)] f0 = foos[0] foos[0] = Foo(a=2)
print(f0.a) # 0 print(foos[0].a) # 2 ```
`foos` is a list of type `Foo`, but it still can't be safely made into a dense list (at least not naively).
It should be noted that PyPy already does unboxing Animats suggested, without any type annotation. At least for 4 years. It is not theoretical. https://morepypy.blogspot.com/2011/10/more-compact-lists-wit...
Python got further with minimal declarations than any other mainstream language. Yet there's a demand for typed variables. This is going into future Python, although in a strange and clunky way, because types don't fit the syntax.
We seem to be converging on a consensus on when to declare types. The breakthrough was "auto", in C/C++, which declares a variable as the type of the value to which it is initialized. This is the default in Go and Rust. Function formal parameters and structure slots have explicit type declarations, while local variables are usually implicitly typed.
Python seems to be moving in this direction, but from the no-type-declarations direction. Unfortunately, because the language itself doesn't do this well, it's being kludged through decorator macros.