4 ms·
To put it crudely, you're thinking with a deity's mindset. PyPy has to accept that annotations can be wrong under this proposal. PyPy is trying to implement Pyt
by drostie 12y ago
To put it crudely, you're thinking with a deity's mindset. PyPy has to accept that annotations can be wrong under this proposal. PyPy is trying to implement Python, and in Python, those annotations are strictly advisory.
PyPy can of course take that mindset, forking the language into some typed python dialect which, for well-typed programs, returns the same stuff as normal Python. Actually, you may be surprised to know that this language has already been completed (!) and a significant program has been written in it (!!). That significant program is called PyPy (wow so meta), and the language it's written in, which alters Python so that static type inference is possible, is called RPython.
But assuming that PyPy doesn't force everyone to write RPython, static type inference cannot be done easily in Python and static type annotations are strictly advisory. Given this, PyPy will keep doing its just-in-time thing. Then, we're compiling while the code is executing. But then what help is a type hint? It's run-time. We have the argument; we know what Python type it is supposed to be. The problems which PyPy has to solve are things like, "can I optimize this Python `int` into a single 64-bit word?" and those problems are not addressed at all by the type hint.
- andreasvc 12y agoI understand static type annotations would be an extension to current Python semantics, it would require a flag such as "my type annotations are correct and please use them for optimizations" (this idea really only makes sense if PyPy can assume the annotations are not wrong, otherwise the arguments against this idea are just trivial). TypeScript is doing something similar for Javascript; it extends the language but is a strict superset. Type annotations can work together with JIT optimizations, because the annotations could simply provide a better starting point for JIT, requiring it to infer less, and perhaps providing information which would otherwise not be inferred from running the code. PyPy would still need to specialize further, e.g., from Int to int64 as you say, but already knowing that it's not float or str or list already seems useful. Gradual typing is relevant in this regard, which makes it possible to combine static and dynamic types and do type inference. See e.g. https://github.com/tomprimozic/type-systems/tree/master/gradual_typing https://github.com/tomprimozic/type-systems/tree/master/grad... Now of course PyPy may hold the position that it's going to eschew static types on principle, but then it's a matter of ideology, not a technical reason, which causes these type annotations to "never have any value for PyPy".