PEP 756: Give up on copying memory

[vstinner]

---

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

[vstinner]

@zooba @pitrou: I tried hard to fit memory copies and conversions in PEP 756, but apparently there are too many drawbacks and most users expect/require O(1) complexity. Here is a change to give up on any kind of implicit conversion and only export what we have in O(1). It means giving up on exporting UTF-8 on CPython 3.14 which is IMO an acceptable tradeoff. You can use PyUnicode_AsUTF8AndSize() which is already available.

[zooba]

Thanks for this change.

I don't know that referring to "most users expect" is necessarily true or helpful, but expectations will certainly be clearer.

[vstinner]

I don't know that referring to "most users expect" is necessarily true or helpful, but expectations will certainly be clearer.

Well, in the PEP 756 discussions, it seems like the majority has the expectation that an export has a O(1) complexity and would be unhappy if somehow an export can cost O(n) on a different Python version or implementation.

[pitrou]

I think the users we're trying to satisfy here are the ones you listed in the PEP: https://peps.python.org/pep-0756/#usage-of-pep-393-c-apis

[zooba]

Well, in the PEP 756 discussions ...

I guess I feel like I dominated the discussion too much and you shouldn't treat me as representing multiple users 😆

I think the users we're trying to satisfy here are ...

Indeed, though I'm only aware of a deep dive going into markupsafe, which did have a legitimate use for O(1) access and was willing to implement their search/replace algorithms multiple times in order to benefit from it. I've got no idea how many others are in the same category, and I don't think many of them spoke up.

[willingc]

Nice edits. Thank you for the clarity.

[vstinner]

Merged, thanks for reviews.