Skip to content
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

PEP 757: Use union #4111

Closed
wants to merge 1 commit into from
Closed

PEP 757: Use union #4111

wants to merge 1 commit into from

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Nov 6, 2024


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

@vstinner
Copy link
Member Author

vstinner commented Nov 6, 2024

@skirpichev: What do you think of using an union in the export?

@skirpichev skirpichev self-requested a review November 6, 2024 15:51
Copy link
Member

@skirpichev skirpichev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With current proposal we don't gain anything. E.g. some contract like "this will not fail for integers".

I'm neutral on keeping the kind field wrt using the return value of PyLong_Export() to encode the union type (yet the struct, probably, will be bigger), as c0a725b does.

@vstinner
Copy link
Member Author

vstinner commented Nov 6, 2024

I'm not changing any contract. It's just the structure which changes to make it more obvious which members should be used depending on the kind.

NameNoQuality

This comment was marked as spam.

Copy link
Member

@skirpichev skirpichev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not changing any contract.

Bad news. I would buy such change if one allows us to skip error checking. Or simplify current implementation (e.g. if only one export type will be used).

It's just the structure which changes to make it more obvious which members should be used depending on the kind.

I think that current PEP shape is simple enough. Lets not rewrite it again ;) I doubt that in future we will need something else than current two versions of export.

With union the structure will be, probably, more compact. This is only benefit of this change, for me. Not sure if it worth.

Count me neutral on this.

Comment on lines +126 to +127
.. c:macro:: PyLongExport_VALUE_KIND ``1``
.. c:macro:: PyLongExport_ARRAY_KIND ``2``
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we expose these details? Lets just keep symbolic constants.

@vstinner
Copy link
Member Author

vstinner commented Nov 7, 2024

Ok, I close this PR.

@vstinner vstinner closed this Nov 7, 2024
@vstinner vstinner deleted the pep757_union branch November 7, 2024 11:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants