How is this "sabotaging" PyPy? Also, even with type declarations, I'm not sure you could get Numpy-esque performance, given that Numpy doesn't have to dereference every element in the array.
If the compiler knows a Python array is uniformly of type float, it can, and should, use a dense array of floats to represent it.
Is this safe in all cases? What about complex types? Specifically if you assign a variable to an element in the array, and then replace the element in the array? You'd have to take care not to update the value of the variable.
Assigning a variable to a destination declared to be an incompatible type should produce an error at compile time if possible, and at at run time otherwise. That's what type declarations are all about.
I think you misunderstand. Here's an example:
``` 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).
You are right. Array elements need to have value semantics to do complete unboxing. But for NumPy-like use cases, they do.
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...
(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.)
[1] https://www.python.org/dev/peps/pep-0484/