pyclass: unify pyclass with its pyo3 arguments

[davidhewitt]

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]

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]

Anyone got any concerns before I merge this one?

[adamreichold]

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]

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!