Regarding ABI issues, I don't see anything obvious either. I was probably misremembering the potential marshal issue, which was addressed.
struct _longobject (the implementation details behind the public PyLongObject typedef name) and the digit definition are excluded from Py_LIMITED_API. So per https://docs.python.org/3.10/c-api/stable.html we are free to change the struct layout. yay. regardless, I have confirmed that, sys.getsizeof(0) returns the same value (12) on a 32-bit build both with 15-bit and 30-bit (--enable-big-digits) builds on 32-bit architectures (I checked arm and x86). So it'd only "break" something depending on non-limited minor version specific ob_digit definitions and using it on the wrong Python version. not a big deal. People wanting that need to use Py_LIMITED_API in their extension code as per our existing policy. The getsizeof increments go from 12 14 16 18 20 to 0digits=12 1digit=16 2digit=20 as expected when doubling the digit size, but this isn't a problem. memory allocator wise, the same amount of ram is going to be consumed by the same magnitude int regardless of how it gets built. nothing allocates and tracks at a 2-byte granularity. Perhaps I missed it, but maybe an action item would be to add a >> buildbot which configures for 15-bit PyLong digits. >> > > Yep, good point. I was wrong to say that "15-bit builds don't appear to > be exercised by the buildbots": there's a 32-bit Gentoo buildbot that's > (implicitly) using 15-bit digits, and the GitHub Actions Windows/x86 build > also uses 15-bit digits. I don't think we have anything that's explicitly > using the `--enable-big-digits` option, though. > My raspbian bot covers the 32-bit use case we primarily care about. (I should promote that to one to stable) I suggest just going for it. Remove 15-bit digit support and clean up the code. My guess is that there will not be a meaningful performance impact on 32-bit hosts. I'm happy to run some tests on a rpi once you've got a PR up if you don't already have a dozen of those laying around. :) -gps > > -- > Mark > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/ZIR2UF7KHYJ2W5Z4A3OS5BDRI3DS5QTM/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UAYEAALSRWZGZWEB7W3QE2LFRCGT5USR/ Code of Conduct: http://python.org/psf/codeofconduct/
