Skip to content
This repository was archived by the owner on Oct 1, 2019. It is now read-only.

Fix nested ifs #85

Merged
merged 2 commits into from
May 11, 2018
Merged

Fix nested ifs #85

merged 2 commits into from
May 11, 2018

Conversation

patrick91
Copy link
Member

Improvement over #20

@patrick91 patrick91 requested review from FuegoFro and j-f1 May 5, 2018 03:18
@patrick91 patrick91 merged commit 28ef42b into master May 11, 2018
@patrick91 patrick91 deleted the fix/nested-multi-if branch May 11, 2018 05:47
Copy link
Collaborator

@FuegoFro FuegoFro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm so sorry I've been taking so long to look at these and that this is late! Maybe we can address some of these comments in a followup PR, or I'm happy to do a followup for some of this stuff :)

I'll try to take a look at everything by the end of this weekend :)

return concat(parts);
if (
parent.ast_type === "If" &&
parent.orelse.length > 0 &&
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'll want to check if length === 1 here to handle cases like

if foo:
    return 1
else:
    if bar:
        bar()
    return 2

right? In any case, it would be nice to have a test case like this (an else with an if and something else after the if).

}

const parts = [
"if ",
type,
" ",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the intent to handle long conditions that need to wrap in a followup diff?

parts.push(
concat([
"else:",
indentConcat([hardline, join(hardline, path.map(print, "orelse"))])
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think instead of the join we want to use printBody which, among other things, will preserve blank lines appropriately.


if (orElse) {
parts.push(orElse);
if (n.orelse[0].ast_type === "If") {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to above, I think this need to also check that n.orelse.length === 1. In fact we might want to pull this out to a is_elif function that operates on the parent If AST node (where "parent" here is n, but earlier in the function is parent). Or maybe a get_elif_node which takes in the parent and either returns the single If node in the orelse or null if it's not an elif node. That would allow us to check for get_elif_node(parent) === n above and get_elif_node(n) !== null here.

Also I'd like to see a comment here explaining why we do it this way. I had to think for a bit to understand why we can't have this n.orelse[0].ast_type === "If" logic only once. Maybe something like

If this is going to be an elif we can't print else: and indent, but rather let the child print elif and indent itself.

foo()
elif bar:
bar()
elif baz:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me that this is what we want. Certainly, if I wrote the original code and it got reformatted to this, I would be frustrated. I think it can make sense to have a single if in an else block, particularly if you're planning to extend it later.

I think to fix this we'd need to look at the source of the If node, given how the AST is desugared. In particular, I think in the above is_elif or get_elif_node function I describe, we could add a check along the lines of n.orelse[0].source.startswith("elif").

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants