-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
Eliminate bindings for partial pattern matches #87920
Comments
This draft PR contains a couple of pattern matching improvements I'm experimenting with. Most significantly, it implements behavior that several people requested during the PEP-634 feedback process: no more name bindings for partial matches. (One caveat: all names are bound *before* evaluating the corresponding guard. If the guard fails, these bindings won't be rolled back before matching the next case.) In short, this is accomplished by storing captured objects on the stack underneath the more immediately important stuff, popping them all on failure or storing them all only once the *entire* pattern for that case matches. The control flow needs to be greatly simplified in order to make this work correctly, so the patch replaces the current "push bools and jump if false a bunch of times" flow with something much more efficient: jumping straight into a run of POP_TOPs on failure. We already do something very similar to this in pattern_helper_sequence_unpack (the comments in the current code explain it well). Parts of the new code are a bit more complex than before (especially or-patterns, which need to do a bit of juggling on the stack to reorder captured items and avoid popping important data on failure), and other parts can certainly still be improved... but I personally consider it a win to have more intuitive partial match behavior with no performance penalty. I thought I'd loop a few of you in on it to hear your thoughts before progressing much further. |
Guido informed me that Mark is currently maintaining a PEP-653 implementation branch. I checked it out today, and it looks like it has *lots* of conflicts with this one. For the time being, I'm going to experiment with other ways of accomplishing this that don't involve rewriting most of the pattern compiler. That way we can minimize potential merge conflicts. |
Since the feature freeze is coming up (and this changes the bytecode), I'd like to open this up for review now. It probably shouldn't actually be merged before the AST changes in bpo-43892, though. There will be quite a few conflicts that need resolving, but I'd rather integrate the AST changes into this PR than force Nick to integrate these deeper changes into his branch. |
New changeset 3949428 by Pablo Galindo in branch 'master': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: