Implement Py38 named expression (PEP 572) - #1934
Merged
windelbouwman merged 26 commits intoJun 1, 2020
Merged
Conversation
…ension, in other cases use regular evaluation order
Contributor
Author
|
Be carefull, when testing it in an existing workspace as the bytecode changed. Although, I set the new instruction to the end, such that it should have no interference with already compiled bytecode files, I cannot ensure it. |
|
thanks for tackling this. codes look quite good |
TheAnyKey
force-pushed
the
TheAnyKey/p38_named_expr
branch
from
May 23, 2020 22:27
3ca1fba to
8bdd69c
Compare
…arinings and cleanup required
TheAnyKey
force-pushed
the
TheAnyKey/p38_named_expr
branch
from
May 24, 2020 17:22
8bdd69c to
3ca1fba
Compare
TheAnyKey
force-pushed
the
TheAnyKey/p38_named_expr
branch
from
May 24, 2020 20:36
3ca1fba to
17008ef
Compare
…invalids are passed. Cleaned up in symboltable
TheAnyKey
force-pushed
the
TheAnyKey/p38_named_expr
branch
from
May 27, 2020 20:36
b4cc2d7 to
1968c5d
Compare
Contributor
Author
|
Mostly done. Just need to add a few more checks, cleanup and merge. Some scoping issues will remain as they are an already existing RustPython problem. So we can fix that with a separate PR. |
Incrementally adding OpenBSD support (pt. 1)
…with-_io Initialize the vm with imports from _io instead of io
…ension, in other cases use regular evaluation order
…arinings and cleanup required
…invalids are passed. Cleaned up in symboltable
…ey/RustPython into TheAnyKey/p38_named_expr
TheAnyKey
marked this pull request as ready for review
May 28, 2020 20:38
coolreader18
approved these changes
May 29, 2020
coolreader18
left a comment
Member
There was a problem hiding this comment.
LGTM, thanks for working on this!
Member
|
@windelbouwman could you take a look at the symbol table changes? |
Contributor
|
Ahh, nice, the infamous walrus operator! := |
…n from symbol resolution. Added some more comments.
…n from symbol resolution. Added some more comments.
…ey/RustPython into TheAnyKey/p38_named_expr
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Python 3.8 instroduced named expressions or assignment expressions with PEP 572. Now it is possible
Most of the CPython tests are already passing. There are some scoping issues with mutli level (e.g., when a comprehension is inside of a comprehension, the asignments from the inner one are not leaked to the scope outside of the outer comrpehension). Further, there are no error messages when (ab)using iterator variables in named expressions. Both are generic topicsin RustPython and require a bit of rework in the symboltable and some other parts. As the functionality is complete besides of the scope limitation I propose to accept this PR.