@encukou @pitrou: I tried to satisfy everybody, I only added a soft requirement on the trailing NUL character. I prefer to not write must here to be more future proof. The PEP also recommends to only rely on Py_buffer.len.

Hm, I'm again confused about which version of the PEP we're discussing :(

Why do we need the flags? Couldn't we put new flags in the requested_formats arg and the result?

Why do we need the flags? Couldn't we put new flags in the requested_formats arg and the result?

I prefer to have a separated parameter for that. I don't think that it would be future proof to mix formats and flags.

Having a flags parameter became a common practice in new Linux syscalls. It helped Linux to not have to add a new syscall each time someone comes with a new use case.

But, we might need flags for the output as well. For example, if you request a string with no lone surrogates, there should be an output flag confirming there are no lone surrogates.

(Alternatively, the export function could fail on unknown flags. But then, we couldn't add a “don't add a terminating NUL” flag in a backwards-compatible way.)

But, we might need flags for the output as well. For example, if you request a string with no lone surrogates, there should be an output flag confirming there are no lone surrogates.

If there is an hypothetical flag to reject surrogate characters, the function must fail if the string contains a surrogate character. There is no need for output other than the error, no?

(Alternatively, the export function could fail on unknown flags.

The function currently fails if flags is not equal to 0.

But then, we couldn't add a “don't add a terminating NUL” flag in a backwards-compatible way.)

Let's say the the hypothetical new flag is added to Python 3.15: you should not pass the flag to Python 3.14. So you should check the Python runtime version using Py_GetVersion(). On Python 3.14, it would fail with an error.

you should check the Python runtime version using Py_GetVersion()

Now we're getting CPython-specific; that would work better as non-limited API.

Now we're getting CPython-specific; that would work better as non-limited API.

Maybe my flags idea is a bad idea and it should just be abandoned :-)

I updated the PR to remove flags again, only remove Open Questions.