-
Notifications
You must be signed in to change notification settings - Fork 782
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
Support for PEP 622 structural pattern matching #1714
Comments
This is definitely interesting, but:
|
TBH I was assuming that (Though they should continue to work perfectly fine on earlier versions too without |
Hi, I wanted to know if I could volunteer to work on this issue. |
Sure, but I am still working on fieldless enums (#2013). I think you can work on pattern matching for tuple struct before #2013 is done to avoid conflicted implementation. (It's almost done, so if you really want to work on pattern matching on enums, you can fork my branch. Just let me know when you fork it so I won't rebase that branch and screw your worrks.) Pattern matching on enums is discussed at #417. @davidhewitt maybe you want to close this as a duplication of #417? |
Thanks for the info, @b05902132. I want to work on pattern matching for tuple structs, so I have forked your branch. |
I'm also new to this project, and not very familiar with the codebase, but I'll try: The details of Python pattern matching is described in PEP634. I think you may want to implement this as a class pattern. If so, you need to add a class attribute named Also if you want to implement pattern matching on enums, I think the best way to do is to implement a subclass to the enum for each variant. (see the discussion in #417). Then you will have to add By the way, If you haven't worked with proc macro before, https://github.com/dtolnay/proc-macro-workshop is extremely helpful for getting yourself familiar around that. If you have more questions, please ask on GItter, so the more experienced contributors can answer them too! |
@errantsky My branch depends on #2014, and as a part of merging that PR, I'm afraid I will have to rebase my branch. I hope you didn't start any work yet 😅 |
@b05902132 Thanks so much for the info. I have not started any work yet, so go ahead and rebase your branch. |
Sorry it's taken me a long time to get around to replying here. The above comments all sound great. I've been thinking a little bit on the design, I think the right solution is for PyO3 to automatically define #[pyclass]
struct Point2d {
x: f64,
y: y64,
}
#[pymethods]
impl Point2d {
#[new]
fn new(x: f64, y: f64) -> Self {
Self { x, y }
}
} then the generated |
I don't think we need
This syntax is also similar to Rust's: struct Point {x : i32, y: i32}
match point {
Point{x=0, y} => ... // Not Point2d(0, y)!
Point{x, y} => ...
} It's very easy to support this form of Pattern matching. When Python sees if isinstance(point, Point) and point.x == 0:
y = point.y
f(y) So the following code already supports pattern matching (by attribute names): #[pyclass]
struct Point{
#[pyo3(get)]
x: i32,
#[pyo3(get)]
y: i32,
} Also, I think there are cases where it's not suitable to generate |
We do, however, need to support tuple structs. In Rust we match them by: struct Point(i32, i32);
match point {
Point(x, y) => ...
} Therefore I think we should support the following: match point:
case Point(x, y):
... I think this can be implemented by adding new descriptors for all tuple structs. |
Right, I see, although class patterns can benefit from
I wouldn't add this automatically; it's a breaking change in behaviour. Users of tuple structs may have non-pub fields in just the same way. Instead I now think that the "default" match behaviour should be left for the PyO3 user to support. We could autogenerate |
I feel that this asserts that if you create two instances of a class using the same arguments, that these instances are then interchangeable. Which isn't necessarily the case. I think it would be best to just leave this up to the user. |
Agreed. It's possibly the case that for enums and |
As per #2065 (comment) we probably need to add |
I took a look at adding such flags, but it seems that doing this via the C-API is only supported in non-abi3 cases. It's probably better to implement support for inheriting from |
From a quick test, looks to me like the new |
Just wanted to ask: New versions of Python have added support for pattern matching (PEP 622):
Would it be possible to extend Pyo3 to support
#[derive(FromPyObject)]
for Rust enums, so that Rust can work natively with these Python enums? According to the specification, all that needs to be done is that the Python interpreter tries to look for new functionsRight now I am emulating this behaviour by having a struct with
#[repr(transparent)]
and a function to create the case:It's not a very high priority, but it would be nice to have. Just wanted to ask if the PyO3 team is aware of this PEP.
The text was updated successfully, but these errors were encountered: