(feat) Adding an InsertBefore feature #70
Conversation
There was a problem hiding this comment.
Can we also have some tests where we insert something at the top of the module, just before the last statement, between two statements using InsertBefore, and doing some mixed stuff with yields (composite actions) where we insert something before and then after and then before in the same match. Probably these should live in the test_actions.py. But overall, amazing PR! Love it.
refactor/actions.py
Outdated
| def _stack_effect(self) -> tuple[ast.AST, int]: | ||
| # Adding a statement right after the node will need to be reflected | ||
| # in the block. | ||
| return (self.node, 1) |
There was a problem hiding this comment.
Since we are adding a statement right before a new node, this needs to be -1 right?
| def _stack_effect(self) -> tuple[ast.AST, int]: | |
| # Adding a statement right after the node will need to be reflected | |
| # in the block. | |
| return (self.node, 1) | |
| def _stack_effect(self) -> tuple[ast.AST, int]: | |
| # Adding a statement right before the node will need to be reflected | |
| # in the block. | |
| return (self.node, -1) |
There was a problem hiding this comment.
I think this is not going to work with _apply_multiple as it seems that the top of the stack is referenced to the input node, setting -1 does not seem to be a meaningful stack effect.
Maybe a Replace+InsertAfter is how to handle the InsertBefore with _apply_multiple?
Adding consideration for negative offset in graph_access.py
|
Looks amazing, all of the tests are super clear and the code is very clean and slick. Thank you so much for working on this ❤️ 💯 |
|
Thank you, that means a lot! Happy New Year! |
|
My mistake, but there is a bug in this commit. The decorators are not pulled-in with the definition: I added the test and figuring out how to quickly resolve it |
Proposing to add the possibility to insert statement before a node. This was found useful when combining 2 methods and needing to conserve the order of execution