This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Devin Jeanpierre, benjamin.peterson, josh.r, mark.dickinson, pitrou, serhiy.storchaka, vstinner, yselivanov
Date 2017-06-15.14:06:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1497535606.19.0.15815752999.issue17870@psf.upfronthosting.co.za>
In-reply-to
Content
> This request was part of the original bug report, so why open a new issue?

Making two C functions public is very different from supporting intmax_t. I expect a change of a few lines, whereas my intmax_t patch modified a lot of code.

I wanted to simplify the C code of CPython, I didn't care of the public support for intmax_t (but I considered that it would be nice to have).

The thing is that portability is complex, CPython wants to support as much platforms as possible. We only moved to C99 with Python 3.6, before stdint.h was not required. There are always minor compatibility issues, so it's simpler to not try to support an uncommon C type (intmax_t), and rather support a very generic functions "here are bytes, give me a Python int object".

It would solve your use case as well ;-)
History
Date User Action Args
2017-06-15 14:06:46vstinnersetrecipients: + vstinner, mark.dickinson, pitrou, benjamin.peterson, Devin Jeanpierre, serhiy.storchaka, yselivanov, josh.r
2017-06-15 14:06:46vstinnersetmessageid: <1497535606.19.0.15815752999.issue17870@psf.upfronthosting.co.za>
2017-06-15 14:06:46vstinnerlinkissue17870 messages
2017-06-15 14:06:46vstinnercreate