[Python-Dev] Type hints -- a mediocre programmer's reaction
Chris Angelico
rosuav at gmail.com
Sun Apr 26 00:55:26 CEST 2015
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. <int16> + <int16> 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
More information about the Python-Dev
mailing list