-
Notifications
You must be signed in to change notification settings - Fork 392
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
Factor out expression codegen from function codegen #155
Conversation
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.
Thanks, I guessed it is the good time to refactor some related things (as I commented) as well.
@@ -0,0 +1,704 @@ | |||
"""Codegen for single expressions.""" |
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.
How about splitting other objects than ExpressionCodegen
into other files too in this PR? Maybe definitions in constants.py
should also be integrated as well.
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.
sure yeah! maybe a bulitin_functions.py
? this would essentially just turn into a rename of the file?
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.
On second thought maybe save other splitting for another PR?
This PR is getting very big, and trying to solve merge conflicts is mildly painful. Would like to merge this in ASAP and further refactors can come in subsequent PRs.
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.
It's fine to prepare a separate PR for this refactoring.
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.
bulitin_functions.py
looks confusing. I guess simply rules.py
or something else would be good.
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.
Maybe it's almost fine. several comments:
src/latexify/analyzers_test.py
Outdated
"3 / 4", | ||
], | ||
) | ||
def test_reduce_stop_parameter_not_binop_with_op_add_or_sub(code: str) -> None: |
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 we don't need to separate test cases into 2 parts.
- Shrink this king of long test names, which are not convenient to read.
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.
Okay, going to bring test case into one method, which solves the issue of long name
@@ -0,0 +1,704 @@ | |||
"""Codegen for single expressions.""" |
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.
It's fine to prepare a separate PR for this refactoring.
@@ -0,0 +1,704 @@ | |||
"""Codegen for single expressions.""" |
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.
bulitin_functions.py
looks confusing. I guess simply rules.py
or something else would be good.
@ZibingZhang @odashi |
Thanks for the catch, apologies for that mistake I made when resolving merge conflicts. |
Great, thanks both! (this kind of collision often happens when we applied large changes, so please never mind. but we should fix it ASAP) |
This PR does not add / remove any functionality, nor does it add / remove any tests. It's purely a refactor.
Overview
Split
function_codegen
into two files like so:function_codegen
that implements visiting module and statements nodes, and delegates toexpression_codegen
for expression nodes.expression_codegen
that implements visiting expression nodes (as well asast.comprehension
.Considerations
How should we test
function_codegen
comprehensively? All tests thatexpression_codegen
have will apply tofunction_codegen
, at least for the time being.References
Initial idea: #57 (comment)
Factor this change out of algorithmic codegen PR: #152 (comment)
Blocked by
None