-
Notifications
You must be signed in to change notification settings - Fork 557
Order variables by closeness to executing statement in pure_eval #807
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
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
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.
Instead of this conditional can't we do
assert set(frame_vars.keys()) == set(expected_keys)
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.
I think you misunderstood.
frame_vars.keys()
is set-like and soassert frame_vars.keys() == set(expected_keys)
would work in all versions.assert list(frame_vars.keys()) == expected_keys
is a stronger assertion to make extra sure (when possible) that values are prioritised as expected. The tests are fine as they are, the reason for the failure in 3.5 is that the implementation actually doesn't work and the values are actually wrong.The problem is that I
return OrderedDict
above so that the trimming inserialize
will keep the first 10 items of the dict, but just before the trimming theOrderedDict
gets converted to adict
(see the PR description) which breaks the order in 3.5 and thus the implementation (the wrong values get trimmed). I'm asking if I should just trim the values within the pure_eval integration and forget theOrderedDict
, or try to preserve order inserialize
.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.
To be clear both options should be equivalent right now, but if
serialize
changes its algorithm and starts trimming things more cleverly in the future, it will be better if it has the full dict of variables in order of priority rather than a dict that was eagerly/preemptively trimmed by pure_eval.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.
Ah right, I recommend going for option 3 but avoiding hardcoding the number 10 (instead importing the var). I don't think there's a safe alternative to
dict
outside of pure_eval context, so I'd like to avoid changes to serializer.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.
I doubt this will happen in serialization, let's assume pure_eval always knows better (seems likely given the amount of extra analysis it does)
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.
Done