[Python-Dev] Type hints -- a mediocre programmer's reaction (original) (raw)
Chris Angelico rosuav at gmail.com
Sun Apr 26 00:55:26 CEST 2015
- Previous message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Next message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sun, Apr 26, 2015 at 2:01 AM, Ronan Lamy <ronan.lamy at gmail.com> wrote:
* PEP484 hints are too high-level. Replacing an 'int' object with a single machine word would be useful, but an 'int' annotation gives no guarantee that it's correct (because Python 3 ints can have arbitrary size and because subclasses of 'int' can override any operation to invoke arbitrary code).
Then create your own int16, uint64 etc types. The PEP doesn't explain how to do that. And even if it's possible, such types wouldn't be very useful as they're not stable under any arithmetic operation (e.g. + doesn't necessarily fit in int16).
If you define a function that adds two integers and want it to be optimized, it's going to have to check for overflow anyway. That said, though, I'd much rather a machine-word optimization be a feature of "int" than a special adornment that you give to some of your data. CPython 3.x doesn't do it, CPython 2.x kinda did it (an int would turn into a long if it got too big, but a long would never turn into an int), but MicroPython would be most welcome to do the job fully. (I would guess that PyPy already does this kind of thing.) Yes, that means integer addition can't become a single machine language instruction, but on the other hand, it means the Python code doesn't need to concern itself with any boundaries.
ChrisA
- Previous message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Next message (by thread): [Python-Dev] Type hints -- a mediocre programmer's reaction
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]