Skip to content

gh-89083: add support for UUID version 6 (RFC 9562) #120650

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

Merged
merged 76 commits into from
Mar 2, 2025

Conversation

picnixz
Copy link
Member

@picnixz picnixz commented Jun 17, 2024

In light of the discussion in #89083, I decided to remove the previous commits on version 7 and 8 and restrict this specific PR to version 6 only. The previous post can be found in the history of this message.

For version 7, please discuss it on #121119.
For version 8, please discuss it on #123224.


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

@picnixz

This comment was marked as resolved.

@picnixz picnixz changed the title gh-89083: support UUID versions 6, 7, and 8 (RFC 9562) gh-89083: support UUID versions 6, 7 (non-monotonous), and 8 (mt19937-based) (RFC 9562) Jun 22, 2024
@picnixz picnixz changed the title gh-89083: support UUID versions 6, 7 (non-monotonous), and 8 (mt19937-based) (RFC 9562) gh-89083: support UUID version 6 (RFC 9562) Jun 28, 2024
@picnixz picnixz changed the title gh-89083: support UUID version 6 (RFC 9562) gh-89083: add ref. impl. for UUID version 6 (RFC 9562) Jun 28, 2024
@merwok
Copy link
Member

merwok commented Jun 28, 2024

I am puzzled by the PR title change – can you explain?

@picnixz
Copy link
Member Author

picnixz commented Jun 28, 2024

Oh yes, after we discussed the v7 implementation, I preferred splitting the PR into 3 with one PR for each version. The ref. impl. means reference implementation but maybe I should have use the expanded wording? (I wanted to have the same title as for the v7 and not a too long title)

@merwok
Copy link
Member

merwok commented Jun 28, 2024

«Reference implementation» makes me think that this code is in support or a spec, and maybe not best-written or optimized for production. If this is not the case, just «implementation» or «support» like before has the right connotations 🙂

@picnixz
Copy link
Member Author

picnixz commented Jun 28, 2024

Sure, I can make the change if you want (I'll edit the other title as well)

picnixz and others added 2 commits February 22, 2025 12:30
Co-authored-by: Victor Stinner <vstinner@python.org>
@picnixz
Copy link
Member Author

picnixz commented Feb 22, 2025

Ideally, I'd like to wait for @hugovk's review as well (for both UUIDv6 and v7 as he also reviewed UUIDv8)

@picnixz
Copy link
Member Author

picnixz commented Feb 23, 2025

I'll hold the merge until we decide on #130461 so that I don't have introduce conflicts in the doc branch.

EDIT: We decided to remove the .. index:: directives in uuid.rst. I'll do the same here.

@merwok merwok marked this pull request as draft February 23, 2025 18:50
@hugovk
Copy link
Member

hugovk commented Feb 25, 2025

I'll hold the merge until we decide on #130461 so that I don't have introduce conflicts in the doc branch.

EDIT: We decided to remove the .. index:: directives in uuid.rst. I'll do the same here.

That issue's PR (#130526) now merged!

@picnixz picnixz marked this pull request as ready for review February 25, 2025 12:40
@picnixz
Copy link
Member Author

picnixz commented Feb 25, 2025

@hugovk I'm not sure why the PR is still marked with an "unresolved review". Is it a bot issue? (maybe re-approving the PR would work?)

@hugovk
Copy link
Member

hugovk commented Feb 25, 2025

Yeah, looks like the draft->ready transition triggers the bot to add the awaiting core review label:

image

And the CI check is:

Error: Label error. Requires exactly 1 of: awaiting merge. Found: type-feature, awaiting core review

https://github.com/python/cpython/actions/runs/13521458821/job/37782590646?pr=120650

I'll re-approve.

@picnixz
Copy link
Member Author

picnixz commented Feb 25, 2025

I'll merge both UUIDv6 and v7 (#121119) by the end of the week, so that other core devs may have a look if they want. I'll also prepare a nice commit message. It's great we managed to land those before the last alpha. Hopefully it will stay during the beta and rc phases as well!

@picnixz picnixz self-assigned this Feb 25, 2025
@picnixz picnixz merged commit 990ad27 into python:main Mar 2, 2025
39 checks passed
@picnixz picnixz deleted the uuid-rfc-9562 branch March 2, 2025 11:42
@picnixz
Copy link
Member Author

picnixz commented Mar 2, 2025

Thank you all for the reviews and the patience!

@hugovk
Copy link
Member

hugovk commented Mar 2, 2025

Thank you for the PRs and your patience! 🚀 :)

seehwan pushed a commit to seehwan/cpython that referenced this pull request Apr 16, 2025
)

Add support for generating UUIDv6 objects according to RFC 9562, §5.6 [1].

The functionality is provided by the `uuid.uuid6()` function which takes as inputs an optional 48-bit
hardware address and an optional 14-bit clock sequence. The UUIDv6 temporal fields are ordered
differently than those of UUIDv1, thereby providing improved database locality.

[1]: https://www.rfc-editor.org/rfc/rfc9562.html#section-5.6

---------

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Victor Stinner <vstinner@python.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants