On Sun, Apr 26, 2015 at 2:01 AM, Ronan Lamy <ronan.l...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
