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

pyclass: unify pyclass with its pyo3 arguments #2234

Merged
merged 2 commits into from
Mar 22, 2022

Conversation

davidhewitt
Copy link
Member

I noticed that the arguments to configure the #[pyclass] macro behaviour were split somewhat arbitrarily between #[pyclass(...)] and #[pyo3(...)].

This PR does some refactoring and unifies the two in a backwards-compatible way, by allowing both forms to take all options. One could describe the new rule as #[pyclass(<stuff>)] is just shorthand for #[pyclass] #[pyo3(<stuff>)].

In the future I'd be quite keen for us to commit on a design one way or another and deprecate the other form. I think we have some time to muse on this.

I think I'd prefer to have #[pyclass(<stuff>)] and not need a separate #[pyo3(...)] accompaniment at all, however I'm not completely sure on that; it might depend on how the #[pymodule] macro evolves in #694.

@davidhewitt
Copy link
Member Author

For reference, the options were previously split as follows:

#[pyclass(
    dict,
    extends = BaseType,
    freelist = N,
    module = "module_name",
    name = "python_name",
    subclass,
    unsendable,
    weakref,
)]
#[pyo3(
    crate = "some::path",
    text_signature = "(arg1, arg2, ...)",
)]
struct Foo { }

Now they can be freely mixed and matched between the two attributes (I think we'd document them all directly on #[pyclass] and keep the pyo3 form mostly for backwards compatibility).

@davidhewitt
Copy link
Member Author

Anyone got any concerns before I merge this one?

@adamreichold
Copy link
Member

Anyone got any concerns before I merge this one?

No concerns about the resulting API. Are the places in the guide which should be modified to be consistent in one way or the other with this change? Should this get a change log entry?

I do not feel versed enough in the PyO3's proc macros yet to really review the implementation. Sorry for that.

@davidhewitt
Copy link
Member Author

No concerns about the resulting API. Are the places in the guide which should be modified to be consistent in one way or the other with this change? Should this get a change log entry?

Good idea, pushed a commit to update various documentation.

I do not feel versed enough in the PyO3's proc macros yet to really review the implementation. Sorry for that.

Heh no worries, the hope is that refactoring like this and removal of #[pyproto] will make the macros code easier to read and maintain in the future!

@davidhewitt davidhewitt merged commit 87c79c0 into PyO3:main Mar 22, 2022
@davidhewitt davidhewitt deleted the pyclass-args-refactor branch March 22, 2022 11:38
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.

2 participants