3 ms·
They wouldn't, because there is no runtime specification for enforcement of types based on type annotations. PyPy still can't assume anything about what type a
by davesque 12y ago
They wouldn't, because there is no runtime specification for enforcement of types based on type annotations. PyPy still can't assume anything about what type a value will be because a value `v` annotated as `str` could still be changed as follows:
v = 1234
Then, PyPy would crash or behave erratically since its assumptions about the value's type are false.
- rwl 12y ago> a value `v` annotated as `str` could still be changed as follows: > v = 1234 Surely at least this could be caught by a static type checker? If `v` is annotated to be of type `str`, assigning it a constant int should be a type error, though I'm sure Python provides more indirect ways of setting `v` that would be harder to catch statically (like globals()['v'] = ...). But your comment raises an interesting question: are the annotations MyPy is relying on (static) type annotations, or value annotations? I tend to think of the difference between static and dynamic typing as whether types attach to expressions or to values. If annotations only attach to the value to which a variable is initially bound in some context, I can see how they really wouldn't be much help in this scenario, since `v = 1234` is simply rebinding `v` to a value of a different type, and a previous annotation wouldn't preclude that. But if annotations attach to expressions, then it would be inconsistent to bind `v` to a value like 1234, since the constant "1234" is of a different type than `v` is.
- bsaul 12y ago"there is no runtime specification for enforcement of types based on type annotations" Indeed, if you consider type annotation as just annotation and nothing else. But at least you "could" imagine an option to have pypy optimize based on them.