gh-89083: add support for UUID version 8 (RFC 9562)

[picnixz]

Simplest implementation of UUIDv8. Extensible implementation where hash functions can be used may be a follow-up PR / feature.

Entropy considerations can be discussed directly on the PR since the issue is becoming larger and larger (but we could also consider opening a separate issue to discuss the implementation more in details).

• Issue: Support UUIDv6, UUIDv7, and UUIDv8 from RFC 9562 #89083

---

📚 Documentation preview 📚: https://cpython-previews--123224.org.readthedocs.build/

[vstinner]

The change mostly LGTM, but there is missing documentation in uuid.rst ("TODO" ;-)).

[vstinner]

By the way, uuid8(a=None, b=None, c=None): I was surprised by the "generic" argument names (a, b, c), but RFC 9562 uses the same names (custom_a, custom_b, custom_c): https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-8

[picnixz]

I had a little interrogation here. Should we use keyword-only parameters (if so, which names? with/without the custom_ prefix?)?

I also wondered whether to keep custom_a or a but if people want to use keywords (without the parameters being keyword-only) the first one does not give more information so the short name is probably preferred to reduce the number of keystrokes...

[vstinner]

I'm fine with uuid8(a=None, b=None, c=None) API: short parameter names (not custom_ prefix) and allow passing arguments as positional arguments.

[vstinner]

Does it make sense / is it possible to reject values outside the expected value range? For example, reject negative numbers?

Maybe something like:

orig_a = a
a &= 0xffff_ffff_ffff
if a != orig_a: raise ValueError("...")

I don't know. Would it be consistent with other uuid functions?

[picnixz]

UUIDv1 does not reject them so I wouldn't worry too much about it. v3 and v5 are not based on integral inputs.

[vstinner]

I'm fine with having the same behavior than uuid1() in this case, since it's documented.

[vstinner]

LGTM but I would prefer to have a second core dev to review the feature.

[hugovk]

(What's New conflict resolved)

[hugovk]

Thanks!

[picnixz]

Thanks Hugo for the review! I've changed the docstrings in tests to regular comments to avoid cluttering the output in verbose mode and used .. versionadded:: next.

[vstinner]

Merged, thanks @picnixz.