-
Notifications
You must be signed in to change notification settings - Fork 17
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
Clarify Nested Blocks pattern #562
Comments
seems we need |
I am for finding out nested blocks with Considering nested blocks of different types, their nesting depth should be greater than for nested blocks of same type. For example triple nested |
When this pattern was suggested, It supposed to match only the nested STATEMENTS of the same kind. |
@Vitaly-Protasov
for example, If [DO, DO, DO] ... and so on. |
I suggest keeping the current functionality. |
@Vitaly-Protasov So to keep current functionality, pattern class needs to accept in its constructor def __init__(self, max_depth: int, *block_types: ASTNodeType):
assert len(block_types) > 0, "Please provide at least single type"
... Also notice, that there is pattern If everything is clear, you may close the issue. |
Once I started to refactor 'Nested Blocks pattern', I faced the misunderstanding of how it should works.
First of all, I found
block_type
argument is undue one, because I think that we do not need to specify the type of statement which we want to search for. I think it is better to find all nested blocks inside each other.To be more clear, let's consider the example:
According to the previous implementation, this pattern only can find 1 string of nested block ( whether it is FOR or IF).
I propose to reimplement it and count 2 string of nested block (both FOR and IF).
Also, could you explain, should we consider this pattern, as for the code snippet below:
Here we have nested for->if->for. Is it nested block or not?
The main question. nested block is nested only into the block with the same type?
The text was updated successfully, but these errors were encountered: