gh-60191: Implement ast.compare #19211
Merged
Conversation
This file contains 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
Member
isidentical
commented
Mar 28, 2020
•
isidentical
commented
- Issue: Provide a way to compare AST nodes for equality recursively #60191
isidentical
force-pushed
the
bpo-15987
branch
2 times, most recently
from
fb272e8 to
d16077b
Compare
hansrajdas
reviewed
Mar 28, 2020
hansrajdas
reviewed
Mar 28, 2020
iritkatriel
reviewed
Aug 11, 2020
|
All commit authors signed the Contributor License Agreement. |
AlexWaygood
changed the title
Use separate helper functions to compare _fields and _attributes, because _attributes are always simple strings. Move the type comparison test to the point where it is relevant, rather than making unnecessary type tests. Add comments to explain the logic in more detail.
The basic functionality here is to compare asts recursively. If compare_fields is False, then the comparison is not recursive. It just compares that the top-level AST objects are the same and have the same attributes. This option doesn't seem interesting enough to offer as a feature. Revise the docstring for compare() to explain the options in more detail.
iritkatriel
reviewed
May 20, 2024
iritkatriel
reviewed
May 21, 2024
In practice the primary effect of this change was for Constant() nodes where the value of two constants were equal without being the same literal type, e.g. ast.compare(Constant(1), Constant(True), compare_types=True) was True. This behavior doesn't seem like it has a very strong motivation, and adds some complexity. We can add it back later if there's a clear need for it.
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
The comparison fundamentally depends on _fields and _attributes, which could be modified by the user. It's not clear that such modifications are sensible or supported by the API, but we can at least make sure comparison doesn't silently ignore those comparisons. Also pass a and b as arguments to helper methods instead of using them from the enclosing scope.
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
|
hey @jeremyhylton, i am currently a bit busy with non-oss stuff so if you'd like feel free to take over the PR (and close this one). whatever is the most convenient (sorry for the CLA being blocked, @ambv just made me aware). |
iritkatriel
reviewed
May 21, 2024
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
Co-authored-by: Irit Katriel <1055913+iritkatriel@users.noreply.github.com>
iritkatriel
reviewed
May 21, 2024
Misc/NEWS.d/next/Library/2020-03-28-21-00-54.bpo-15987.aBL8XS.rst
Outdated
Show resolved
Hide resolved
iritkatriel
approved these changes
May 21, 2024
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
JelleZijlstra
approved these changes
May 21, 2024
estyxx
pushed a commit
to estyxx/cpython
that referenced
this pull request
Jul 17, 2024
* bpo-15987: Implement ast.compare Add a compare() function that compares two ASTs for structural equality. There are two set of attributes on AST node objects, fields and attributes. The fields are always compared, since they represent the actual structure of the code. The attributes can be optionally be included in the comparison. Attributes capture things like line numbers of column offsets, so comparing them involves test whether the layout of the program text is the same. Since whitespace seems inessential for comparing ASTs, the default is to compare fields but not attributes. ASTs are just Python objects that can be modified in arbitrary ways. The API for ASTs is under-specified in the presence of user modifications to objects. The comparison respects modifications to fields and attributes, and to _fields and _attributes attributes. A user could create obviously malformed objects, and the code will probably fail with an AttributeError when that happens. (For example, adding "spam" to _fields but not adding a "spam" attribute to the object.) Co-authored-by: Jeremy Hylton <jeremy@alum.mit.edu>
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.