gh-128706: Evaluate constant comparisons in fold_compare
#128705
Conversation
WolframAlph
commented
Jan 10, 2025
•
WolframAlph
commented
- Issue: Comparison operators could benefit from constant folding #128706
WolframAlph
changed the title
fold_comparefold_compare
|
Please fix failing tests and add a few more tests in test_ast :-) |
tomasr8
changed the title
fold_comparefold_compare
|
You can remove the "is" optimization for now for example. |
|
Okay, so as @vstinner suggested, I removed folding of |
|
@picnixz I guess I addressed all of your comments. Also refactored switch a bit to factor out common logic and added |
Misc/NEWS.d/next/Core_and_Builtins/2025-01-10-18-42-57.gh-issue-128706.4T2XSt.rst
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
The addition seems small enough but I prefer that an AST expert confirms whether this addition is truly needed or not. ISTM that it could be used for constant propogation but depending on how we implement the latter, maybe we should only do this at that time.
| @@ -210,6 +210,10 @@ configuration mechanisms). | |||
|
|
|||
| Other language changes | |||
| ====================== | |||
| * Constant comparsion expressions are now folded and evaluated before runtime. | |||
There was a problem hiding this comment.
Do we have a terminology that would be like "at compilation time" instead of "before runtime"? (using "compilation" time may cause users to think that it's only when .pyc files are created but this can be skipped with -B I think?)
| @@ -210,6 +210,10 @@ configuration mechanisms). | |||
|
|
|||
| Other language changes | |||
| ====================== | |||
| * Constant comparsion expressions are now folded and evaluated before runtime. | |||
There was a problem hiding this comment.
I don't know how we are actually ordering the changes. Since this is a fairly niche optimization, I would put it at the end of the list.
There was a problem hiding this comment.
Usually, new changes are added at the end of a section.
|
As I already mentioned I would expect programming language to make such optimizations regardless how practical or impractical they are. But this my personal opinion and everyone if free to disagree. As I also mentioned this becomes more practical when/if constant propagation is implemented, but as @picnixz mentioned probably it should be addressed when the time comes. I would ask participants/AST experts to come to an agreement. I am under no circumstances pushing this, but I would like to know if I should spend time addressing comments in the code if ultimately this will be rejected. cc @Eclips4 |
| } | ||
| int op = asdl_seq_GET(ops, i); | ||
| if (op == Is || op == IsNot) { | ||
| /* Do not fold "is" and "is not" expressions since this breaks |
There was a problem hiding this comment.
| /* Do not fold "is" and "is not" expressions since this breaks | |
| /* Do not fold "is" and "is not" expressions since it would break |
| @@ -210,6 +210,10 @@ configuration mechanisms). | |||
|
|
|||
| Other language changes | |||
| ====================== | |||
| * Constant comparsion expressions are now folded and evaluated before runtime. | |||
| For example, expressions like: ``"str" in ("str",)`` or ``1 == 1.0 == True`` | |||
| are now pre-evaluated. | |||
There was a problem hiding this comment.
| are now pre-evaluated. | |
| are now pre-evaluated during compilation. |
| @@ -210,6 +210,10 @@ configuration mechanisms). | |||
|
|
|||
| Other language changes | |||
| ====================== | |||
| * Constant comparsion expressions are now folded and evaluated before runtime. | |||
There was a problem hiding this comment.
Usually, new changes are added at the end of a section.
|
Closing, as the linked issue has been closed as "wont implement". Thanks for your interest in improving CPython; unfortunately this feature has been rejected. |
