Skip to content

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 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 <[email protected]>
Co-authored-by: Victor Stinner <[email protected]>
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