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

allow constructor customization of complex enum variants #4158

Merged
merged 5 commits into from
May 9, 2024

Conversation

Icxolu
Copy link
Contributor

@Icxolu Icxolu commented May 4, 2024

This is an (experimental) idea I had to support customization of the macro generated constructors for complex enum variants.

This allow placing the the #[pyo3(signature = ...)] attribute on complex enum variants and applies it to the generated constructor.
This way all the normal functionality of signature customization can also be applied for these generated constructors.

What I'm not completely sure about is whether we should reuse the signature name here, or whether we should have have some kind of alias like #[pyo3(constructor = ...)]. On one hand people are already familiar with how signature works, but using it on an enum variant (or anything that's not a function for that matter) is not so intuitive.

Closes #4109

@davidhewitt
Copy link
Member

davidhewitt commented May 6, 2024

I like this idea! I'll try to review the full code tomorrow, though I have some initial thoughts about how this extends:

  • it would be awesome to support something like this for #[pyclass] to automatically generate the #[new] in that case too. Is signature the right name in that case? I feel like constructor, new, or even init might be stronger choices when it's adding a function to the class?
  • re signature vs constructor, the only conflict I can think of is that we might want to allow users to do something like constructor = "some_func" in cases where the auto-generated constructor isn't enough. Or maybe we should have #[new(MyVariant)] in #[pymethods] for that case, if that's technically viable?

@Icxolu
Copy link
Contributor Author

Icxolu commented May 6, 2024

  • it would be awesome to support something like this for #[pyclass] to automatically generate the #[new] in that case too. Is signature the right name in that case?

Yeah, that came up in #4109 (comment) too. I think that extension is a good argument to go with a more descriptive keyword for that context.

  • re signature vs constructor, the only conflict I can think of is that we might want to allow users to do something like constructor = "some_func"

Hmm, interesting idea. It might be pretty tricky to guarantee that the correct variant is constructed if we open this for users.

@davidhewitt
Copy link
Member

  • re signature vs constructor, the only conflict I can think of is that we might want to allow users to do something like constructor = "some_func"

Hmm, interesting idea. It might be pretty tricky to guarantee that the correct variant is constructed if we open this for users.

Ah, very true, I guess we probably cannot, which is a good reason not to add that. And they can always add their own #[staticmethod] or #[classmethod] which constructs the variants anyway.

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

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

This looks good to me! 👍

Just a few small suggestions, and this also needs documentation before it can be merged.

pyo3-macros-backend/src/pyclass.rs Outdated Show resolved Hide resolved
pyo3-macros-backend/src/pyclass.rs Outdated Show resolved Hide resolved
pyo3-macros-backend/src/pyclass.rs Show resolved Hide resolved
pytests/src/enums.rs Show resolved Hide resolved
@Icxolu
Copy link
Contributor Author

Icxolu commented May 9, 2024

I've added to the complex enum section of the guide and put the attribute in the pyclass options table. Is there any other place where we want to mention this?

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

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

I think that's sufficient for now, thanks!

Comment on lines 725 to 727
Ok(quote! { #cls::#variant_name => #repr, })
})
.collect::<Result<TokenStream>>()?;
Copy link
Member

Choose a reason for hiding this comment

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

I think this collect can be made infallible again.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah, yes. I reverted it to how it was before 👍

@davidhewitt davidhewitt added this pull request to the merge queue May 9, 2024
Merged via the queue into PyO3:main with commit 7beb64a May 9, 2024
42 of 43 checks passed
@Icxolu Icxolu deleted the issue/4109 branch May 9, 2024 22:04
@EricLBuehler
Copy link

@davidhewitt, @Icxolu thank you for implementing this!

@Icxolu Icxolu mentioned this pull request May 10, 2024
6 tasks
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.

Default values in enum struct-variants
3 participants