-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PEP 757: reject more ideas #4017
Conversation
* drop endianness field of the PyLongLayout struct * keep PyLong_GetNativeLayout() function (was: open question) * reject mpz_import/export-like API Co-authored-by: Victor Stinner <[email protected]>
788722a
to
f676d54
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
If you'd said "experience has proven that we never need non-native endianness..." then I might have agreed, but my opposition is entirely that we don't know for sure and nobody is willing to pretend that they do. Better to include the information we have rather than assume it (explicit is better than implicit). At a cost of one field in a probably static structure, I don't see why we wouldn't future-proof ourselves. |
@zooba, but can we have some clue on why someone will want to use non-native endianness for digits? This is not for some storage format, but for an implementation of big integers. Such implementation will be much less efficient than one using some machine integer type (and thus, native endianness) for digits. I would agreed here with Mark Shannon: "I don’t think endian is unnecessary. Digits are not composed of bytes, but of larger machine integers, so they don’t really have endianness."
This information (endianness) is already available (e.g. via public macros). The mpz_import/export API have |
I can speculate and invent ideas all day long, but I don't want to waste time. For any idea I invent, we can spend ages arguing about that particular idea, but the point is that we don't know for sure. The only argument I will accept is that you somehow do know for sure, because you've exhausted every possible implementation of storing numbers and found that it's absolutely impossible to need non-native endianness. And I'd be skeptical of that claim if you made it, as I'd hope you also would be (and I note that you've never made that claim yet :) )
We're discussing an API that is exported as a function and not necessarily only going to be used by C developers compiling against this particular version of CPython. We cannot assume that public macros are available - certainly not ones that come from the configure script. The limited APIs have to stand alone from that. (This is very much a limited API/stable ABI matter - unstable APIs can rely on macros, because we require that people build their extensions for specific Python versions/platforms in that case. The limited API is not the same.) |
I think we can. If you don't trust me - trust Mark;)
Only to make implementation more slow. Any other reason of not using machine integer types for "digits"? @vstinner, I'm sure this extra field is useless. But it's not a big deal. If you feel that removing will block accepting proposed API - let me know, I'll quickly revert that part.
Mentioned macros are available in compilers (e.g. in gcc you can use check like And for our application - people even won't do this: mpz_import/export's |
Merged, thanks. |
@vstinner, could you please update description of the d.p.o thread? "Abstract" lists absent function, "open questions" section could be also removed. |
Done: https://discuss.python.org/t/pep-757-c-api-to-import-export-python-integers/63895 |
drop endianness field of the PyLongLayout structI would appreciate also @zooba opinion on (1). Personally I see no reasons to use non-native endianness for implementation of big integers.
(2) was taken from #3980; it seems nobody from C-API WG objected on extra API call added, so lets keep this as a more convenient interface.
PEP 123: Summary of changes
)📚 Documentation preview 📚: https://pep-previews--4017.org.readthedocs.build/