PEP 757: edits, based on C-API WG feedback

[skirpichev]

• Change is either:
  • To a Draft PEP
  • To an Accepted or Final PEP, with Steering Council approval
  • To fix an editorial issue (markup, typo, link, header, etc)
• PR title prefixed with PEP number (e.g. PEP 123: Summary of changes)

// capi-workgroup/decisions#45

---

📚 Documentation preview 📚: https://pep-previews--4026.org.readthedocs.build/

[willingc]

Thanks @skirpichev.

[skirpichev]

PEP updated to roughly follow @encukou proposal in the d.p.o thread. Accompanying change in the implementation: vstinner/cpython#7 (this uses anonymous union for now). Just one export "view" kept: a digit array, valid for all integers for now.

The export benchmark should be unaffected.

PS: It would be nice if we could put an upper bound on size of integers in the default branch. Then instead of abort() or raising an exception - we could fall back on PyLong_AsNativeBytes() to do successful conversion.

[willingc]

Please address feedback related to "big enough" integers.

[willingc]

Thanks @skipichev. I really like the latest commit from you. The concepts are now much more understandable. Great job.

[vstinner]

As the PEP co-author, I'm against removing PyLongExport.value member.

[skirpichev]

Ok, Victor, but please listen first to my arguments.

1. PyLong_Export API should provide maximally transparent access to internals of int's, especially in case of "big" integers (where currently no public API exists);
2. the "array of digits" view is valid now for all integers;
3. the int64_t value view currently is redundant and is a kind of optimization, that has some benefits on some workloads and some drawbacks on others; pros and cons also will depend on the used bigint library;
4. neither gmpy2, nor Sage currently use PyLong_AsLongAndOverflow "hack" (in fact, my patch with such optimization was rejected before);
5. so, I think it's better to leave users with a simple export format and let them make suitable optimizations explicitly;
6. things slightly simpler on the CPython side: we have just one export type.

[pitrou]

@skirpichev You've already said so a number of times on Discourse, how is it useful to rehash it here? You're not the only potential consumer for this API, and you're also not a CPython maintainer AFAIK.

[efimov-mikhail]

Thanks for the clarification about using PyLongWriter_Discard.

[skirpichev]

Now changes in the PyLongExport struct and PyLong_Export API (return type) - reverted.

[vstinner]

LGTM, but I cannot merge your PR since it's a draft.

FYI export_long name is needed in the implementation because export is a reserved keyword in C++ (I don't recall in which C++ version, maybe C++20). But for the PEP, we can use export name.