[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?
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/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-12-24 - 2021-12-31) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7195 ( -1) closed 50747 (+41) total 57942 (+40) Open issues with patches: 2871 Issues opened (32) == #46118: Migrate importlib.resources into a package https://bugs.python.org/issue46118 reopened by jaraco #46175: Zero argument super() does not function properly inside genera https://bugs.python.org/issue46175 opened by tritium #46177: can't install launcher for all users https://bugs.python.org/issue46177 opened by Amine #46178: Remove `.travis.yml`? https://bugs.python.org/issue46178 opened by sobolevn #46180: Button clicked failed when mouse hover tooltip and tooltip des https://bugs.python.org/issue46180 opened by Jason990420 #46181: Destroying an expaned Combobox prevents Entry focus until Alt+ https://bugs.python.org/issue46181 opened by j.lahav #46182: `super` and descriptor clarification https://bugs.python.org/issue46182 opened by Arthur-Milchior #46184: Remove `netlify.toml`? https://bugs.python.org/issue46184 opened by sobolevn #46186: replace `io.IncrementalNewlineDecoder` with non incremental ne https://bugs.python.org/issue46186 opened by guoci #46187: Optionally support rounding for math.isqrt() https://bugs.python.org/issue46187 opened by rhettinger #46192: Optimize builtin functions min() and max() https://bugs.python.org/issue46192 opened by colorfulappl #46194: Wrong base class for transport returned by loop.create_datagra https://bugs.python.org/issue46194 opened by asvetlov #46195: Annotated and Optional get_type_hints buggy interaction https://bugs.python.org/issue46195 opened by med2277 #46196: documentation for cmd library should include columnize() funct https://bugs.python.org/issue46196 opened by sharewell #46197: ensurepip bootstrap breaks out of isolated environment https://bugs.python.org/issue46197 opened by kcdodd #46198: Duplicated test name `test_get_unstructured_invalid_ew` in `te https://bugs.python.org/issue46198 opened by sobolevn #46199: Calculation influenced by print https://bugs.python.org/issue46199 opened by wby78826 #46200: Discourage logging f-strings due to security considerations https://bugs.python.org/issue46200 opened by ariebovenberg #46201: PEP 495 misnames PyDateTime_DATE_GET_FOLD https://bugs.python.org/issue46201 opened by drougge #46202: remove opcode POP_EXCEPT_AND_RERAISE https://bugs.python.org/issue46202 opened by iritkatriel #46203: Add timeout for Windows build steps https://bugs.python.org/issue46203 opened by mark.dickinson #46204: Graphlib documentation (general cleanup) https://bugs.python.org/issue46204 opened by dam1784 #46205: Race condition in runtest_mp leads to hangs (never exits) https://bugs.python.org/issue46205 opened by colesbury #46206: Crash when editing emoji containing strings https://bugs.python.org/issue46206 opened by 10maurycy10 #46207: Log emit performance degradation in RotatingFileHandlers due t https://bugs.python.org/issue46207 opened by dfritz #46208: os.path.normpath change between 3.11.0a2 and 3.11.0a3+ https://bugs.python.org/issue46208 opened by hugovk #46209: add documentation for decoding newlines in the `io` module https://bugs.python.org/issue46209 opened by guoci #46210: print deadlocks https://bugs.python.org/issue46210 opened by notarealdeveloper #46211: Recursively calling makepasv() finally leads to core dumped. https://bugs.python.org/issue46211 opened by xxm #46212: Avoid temporary `varargs` tuple creation in argument passing https://bugs.python.org/issue46212 opened by colorfulappl #46213: webbrowser.open doesn't work in Termux https://bugs.python.org/issue46213 opened by DonaldDuck1313 #46214: Remove unused opcode ROT_FOUR https://bugs.python.org/issue46214 opened by iritkatriel Most recent 15 issues with no replies (15) == #46214: Remove unused opcode ROT_FOUR https://bugs.python.org/issue46214 #46213: webbrowser.open doesn't work in Termux https://bugs.python.org/issue46213 #46211: Recursively calling makepasv() finally leads to core dumped. https://bugs.python.org/issue46211 #46210: print deadlocks https://bugs.python.org/issue46210 #46209: add documentation for decoding newlines in the `io` module https://bugs.python.org/issue46209 #46207: Log emit performance degradation in RotatingFileHandlers due t https://bugs.python.org/issue46207 #46205: Race condition in runtest_mp leads to hangs (never exits) https://bugs.python.org/issue46205 #46204: Graphlib documentation (general cleanup) https://bugs.python.org/issue46204 #46203: Add timeout for Windows build steps https://bugs.python.org/issue46203 #46202: remove opcode POP_EXCEPT_AND_RERAISE https://bugs.python.org/issue46202 #46201: PEP 495 misnames PyDateTime_DATE_GET_FOLD
[Python-Dev] Requesting a code review for #29560 (bpo-26175: Implement io.IOBase interface for SpooledTemporaryFile)
Hi all, I submitted my first PR against Python a month or so ago and was wondering if someone could take a quick look at it and let me know if anything needs to be fixed before it can be merged. It's a pretty simple change (mostly just boilerplate delegation) that allows SpooledTemporaryFile objects to be used like all other io.IOBase objects. This brings it more inline with the documentation, as well as fixes a variety of use cases that require the `seekable`, `readable`, etc. methods to be available on it. Python bug: https://bugs.python.org/issue26175 Current PR: https://github.com/python/cpython/pull/29560 Thanks! Carey ___ 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/B3PPGZJYAOHPNFP5ECJ3REC3DEYCVPGC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?
On Fri, Dec 31, 2021 at 12:40 PM Skip Montanaro wrote: > 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. -- 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] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?
Perhaps I missed it, but maybe an action item would be to add a buildbot which configures for 15-bit PyLong digits. Skip ___ 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/ZXPOXNYDZXAI3ZVXMSQCSL6YFLQDKKMA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?
Thanks all! So to summarize: - 15-bit digits are still very much in use, and deprecating the option would likely be premature at this point - the main users are old 32-bit (x86), which it's difficult to care about too much, and new 32-bit (principally ARM microarchitectures), which we *do* care about So my first suspicion is just downright wrong. In particular, the decade-old logic that chooses 15-bit digits whenever SIZEOF_VOID_P < 8 is still in place (albeit with a recent modification for WebAssembly). For the second suspicion, that "There are few machines where using 15-bit digits is faster than using 30-bit digits.", we need more data. It looks as though the next step would be to run some integer-intensive benchmarks on 32-bit ARM, with both --enable-big-digits=15 and --enable-big-digits=30. If those show a win (or at least, not a significant loss) for 30-bit digits, then there's a case for at least making 30-bit digits the default, which would be a first step towards eventually dropping that support. GPS: I'm not immediately seeing the ABI issue. If you're able to dig up more information on that, I'd be interested to see it. Mark On Fri, Dec 31, 2021 at 3:33 AM Tim Peters wrote: > >> The reason for digits being a multiple of 5 bits should be revisited vs > >> its original intent > > > I added that. The only intent was to make it easier to implement > > bigint exponentiation easily ... > > That said, I see the comments in longintrepr.h note a stronger constraint: > > """ > the marshal code currently expects that PyLong_SHIFT is a multiple of 15 > """ > > But that's doubtless also shallow. > ___ 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/LLGLC7XMTFC5JVFVP45HJ7Y7DAOQUV3I/ Code of Conduct: http://python.org/psf/codeofconduct/
