This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2012年09月20日 18:43 by Julian, last changed 2022年04月11日 14:57 by admin.
| Pull Requests | |||
|---|---|---|---|
| URL | Status | Linked | Edit |
| PR 1368 | closed | louielu, 2017年05月01日 14:47 | |
| PR 1375 | closed | louielu, 2017年05月02日 08:03 | |
| PR 14970 | open | flavianhautbois, 2019年07月26日 20:49 | |
| PR 19211 | open | BTaskaya, 2020年03月28日 18:12 | |
| Messages (17) | |||
|---|---|---|---|
| msg170826 - (view) | Author: Julian Berman (Julian) * | Date: 2012年09月20日 18:43 | |
As is, as far as I can tell, there's no way to easily compare two AST nodes to see if they have the same children and same fields (recursively). I'm writing some unit tests for a NodeTransformers, so I've settled for comparing `ast.dump()`s of each, which is kind of dirty, but 1) works and 2) produces reasonable failure messages. (As a side note of what else I've tried, comparing, say, a list of the `iter_child_nodes` is not a good alternative, since the tests I'm writing are making assertions that a given node was not modified, which means they deepcopy the node and then want to assert that the "transformed" node is unchanged.) I don't know the global implications of changing ast.AST.__eq__ to know if that's feasible (hopefully someone will comment on that), but if it isn't, another provided way would be nice. |
|||
| msg170907 - (view) | Author: Benjamin Peterson (benjamin.peterson) * (Python committer) | Date: 2012年09月21日 17:42 | |
This is a reasonable request. Should comparison include lineno/col_offset or not? If you implement, __eq__, you should also implement __hash__. Maybe, it would be best to start with a helper comparison function in the ast module. |
|||
| msg170909 - (view) | Author: Julian Berman (Julian) * | Date: 2012年09月21日 18:12 | |
I'd say yes (to both lineno/col_offset). And yeah that sounds like what I had in mind (a helper function). If I'm specific for a moment about implementation, perhaps something like `ast.diff`, which yielded tuples of differing nodes (in say, breadth first order down the tree) from two given nodes, and took args for configuration, compare_lineno and compare_col_offset (both defaulted to True), and then __eq__ was just `next(ast.diff(self, other, compare_lineno=True, compare_col_offset=True), None) is None`. Sound good to you? |
|||
| msg171000 - (view) | Author: Benjamin Peterson (benjamin.peterson) * (Python committer) | Date: 2012年09月22日 14:46 | |
Yes, though some things like what to return if one has an entire subtree that the other doesn't have will have to be worked out. |
|||
| msg185288 - (view) | Author: Brett Cannon (brett.cannon) * (Python committer) | Date: 2013年03月26日 18:13 | |
I have a use for this as well, but w/o the lineno/col_offset comparison and all I need is a True/False result. |
|||
| msg185289 - (view) | Author: Brett Cannon (brett.cannon) * (Python committer) | Date: 2013年03月26日 18:17 | |
IOW I think a function that uses ast.walk() and has flags for specifying whether _attributes should also be checked and then uses a class check and then uses _fields to do all other checking. |
|||
| msg292656 - (view) | Author: Louie Lu (louielu) * | Date: 2017年05月01日 10:04 | |
If we only need a binary True/False result, could we just return a compare of dump(a) == dump(b)? This can also add the include_attributes flags for need. |
|||
| msg292665 - (view) | Author: Louie Lu (louielu) * | Date: 2017年05月01日 14:50 | |
Provide a recursive way to compare AST nodes, it will compare with fields, but no attributes. The performance compare with ast.dump methods in unittest # Recursive compare ./python -m unittest test.test_ast.ASTCompareTest ...... ---------------------------------------------------------------------- Ran 6 tests in 0.669s OK # ast.dump compare ./python -m unittest test.test_ast.ASTCompareTest ...... ---------------------------------------------------------------------- Ran 6 tests in 2.192s |
|||
| msg292717 - (view) | Author: Louie Lu (louielu) * | Date: 2017年05月02日 06:35 | |
Update to AST base type richcompare. the unittest finished time was better than python version: Ran 7 tests in 0.278s |
|||
| msg341541 - (view) | Author: anthony shaw (anthony shaw) | Date: 2019年05月06日 15:39 | |
This discussion is inconclusive and targets an old version of CPython, can this issue be closed? |
|||
| msg341546 - (view) | Author: anthony shaw (anthonypjshaw) * (Python triager) | Date: 2019年05月06日 15:49 | |
Closing issue, PR branch has since been removed and targets Python 3.4 |
|||
| msg341555 - (view) | Author: STINNER Victor (vstinner) * (Python committer) | Date: 2019年05月06日 16:23 | |
Please don't close an issue too fast. The PR 1368 is still open and contains valuable code. Moreover, I don't see anyone here saying that the feature is a bad idea. The feature has not been implemented, so the issue should remain open, even if PR 1368 is outdated. > ...issue... targets Python 3.4 Well, it's just that the issue has been created a long time ago, but the feature request remain value for Python 3.8. |
|||
| msg342118 - (view) | Author: Ivan Levkivskyi (levkivskyi) * (Python committer) | Date: 2019年05月10日 18:44 | |
Btw, I am +1 on this feature (preferably with an option to check line, column, end line, and end column). I always wanted this, but never had time to actually implement this. |
|||
| msg348545 - (view) | Author: Philip Dye (Philip Dye) | Date: 2019年07月27日 14:32 | |
If consensus has been reached on this, I am willing to do the work. |
|||
| msg349185 - (view) | Author: Ivan Levkivskyi (levkivskyi) * (Python committer) | Date: 2019年08月07日 17:55 | |
> If consensus has been reached on this, I am willing to do the work. It looks like there is already an active PR https://github.com/python/cpython/pull/14970, there are some non-implemented comments from a core review. |
|||
| msg365213 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) | Date: 2020年03月28日 14:46 | |
I am not sure that implementing a rich comparison of AST nodes is the right way. There are too much options (compare attributes or not, compare recursively or not, compare types or not) and __eq__ does not support options. In addition, it requires implementing compatible __hash__, but how do you implement a hash of mutable object? In addition, recursive comparison can introduce a regression in existing code -- instead of fast returning False the comparison will spent a nontrivial amount of time. If implement a comparison of AST nodes, it should be a separate function which support multiple options. Would be nice also to have examples where this feature can be used before implementing it. See also issue37792. |
|||
| msg365215 - (view) | Author: Batuhan Taskaya (BTaskaya) * (Python committer) | Date: 2020年03月28日 15:24 | |
The solution to hashing used in PR 14970 was just using the default hashing function which is kind of a workaround to the real problem. I now concur with your comments. Will try to draft out an `ast.compare` function. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:36 | admin | set | github: 60191 |
| 2020年03月28日 18:12:54 | BTaskaya | set | pull_requests: + pull_request18574 |
| 2020年03月28日 15:24:16 | BTaskaya | set | nosy:
+ BTaskaya messages: + msg365215 |
| 2020年03月28日 14:46:54 | serhiy.storchaka | set | nosy:
+ serhiy.storchaka messages: + msg365213 |
| 2020年01月29日 00:39:26 | brett.cannon | set | nosy:
- brett.cannon |
| 2019年08月07日 17:55:31 | levkivskyi | set | messages: + msg349185 |
| 2019年07月29日 15:46:44 | vstinner | set | nosy:
- vstinner |
| 2019年07月27日 14:32:06 | Philip Dye | set | nosy:
+ Philip Dye messages: + msg348545 |
| 2019年07月26日 20:49:25 | flavianhautbois | set | keywords:
+ patch stage: resolved -> patch review pull_requests: + pull_request14739 |
| 2019年05月10日 18:44:54 | levkivskyi | set | nosy:
+ levkivskyi messages: + msg342118 |
| 2019年05月10日 01:57:24 | vstinner | set | versions: + Python 3.8, - Python 3.4 |
| 2019年05月06日 16:23:18 | vstinner | set | status: closed -> open resolution: out of date -> messages: + msg341555 |
| 2019年05月06日 15:49:53 | anthonypjshaw | set | status: open -> closed nosy: + anthonypjshaw messages: + msg341546 resolution: out of date stage: test needed -> resolved |
| 2019年05月06日 15:39:40 | anthony shaw | set | nosy:
+ anthony shaw messages: + msg341541 |
| 2017年05月02日 08:03:22 | louielu | set | pull_requests: + pull_request1483 |
| 2017年05月02日 06:35:21 | louielu | set | messages: + msg292717 |
| 2017年05月01日 14:50:15 | louielu | set | messages: + msg292665 |
| 2017年05月01日 14:47:38 | louielu | set | pull_requests: + pull_request1477 |
| 2017年05月01日 10:04:21 | louielu | set | nosy:
+ louielu messages: + msg292656 |
| 2013年03月26日 18:17:47 | brett.cannon | set | messages: + msg185289 |
| 2013年03月26日 18:13:23 | brett.cannon | set | messages: + msg185288 |
| 2012年09月22日 14:46:03 | benjamin.peterson | set | messages: + msg171000 |
| 2012年09月22日 01:30:40 | terry.reedy | set | stage: test needed versions: - Python 3.3 |
| 2012年09月21日 18:12:13 | Julian | set | messages: + msg170909 |
| 2012年09月21日 17:42:12 | benjamin.peterson | set | nosy:
+ benjamin.peterson messages: + msg170907 |
| 2012年09月21日 12:42:10 | brett.cannon | set | nosy:
+ brett.cannon |
| 2012年09月20日 21:30:11 | vstinner | set | nosy:
+ vstinner |
| 2012年09月20日 18:43:56 | Julian | create | |