-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Fixes evaluation order in expression lists #5579
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
Conversation
@ivan-shrimp Hi, thank you for contributing. Is this still a draft or done? |
This PR is complete as is. Feel free to merge this first. I've marked this as draft because I'd like to fix the
In both cases, we should instead perform some "update using mapping" operation. Also, since the unpacking process is externally observable (evaluation order; and for calls, how non- Feel free to take this up; I won't have the time in the very near future, and for myself it's easy to work around this. |
don't emit a no-op when unpacking a single element assume positional args stored as tuple in extended call
ba69069
to
bef2639
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The patch looks really good. Thank you so much for contributing!
Enforce left-to-right evaluation with list/tuple/set expressions and positional arguments in calls.
We cannot iterate through the
*
-unpacked iterables after evaluating all given expressions. This PR fixes the problem by temporarily collecting the unpacked iterable into a tuple before moving on to the next element.Fixes #5566
(
**
-unpacking withdict
s and keyword arguments seem to be more buggy; working on a fix.)