3 ms·
This example seems contrived. I used to swear by clean demarcations of expressions because of this logic, but in practice the return values of nested expression
by duped 5y ago
This example seems contrived. I used to swear by clean demarcations of expressions because of this logic, but in practice the return values of nested expressions are so rarely the same, and always reviewed before merge, with at least some kind of test or that would make this obvious, it would be almost unnoticeable.
For example :
for i in range(0, m) :
for j in range(0, n) :
... inner ...
... outer ...
If `...inner...` is dedented then you will almost certainly get a compilation error since it is referencing `j`. If `j` is not referenced at all, you'll get a linter error saying "unused variable, j".
Additionally, you probably wouldn't want to write nested for-loops anyway, but something like flattening the inner loop into a return value.
- dragonwriter 5y ago> If `...inner...` is dedented The problem usually isn’t …inner… being dedented, but …outer… being indented. Which usually won’t produce an error, since anything that could be in …outer… could also be in …inner… without error. > Additionally, you probably wouldn’t want to write nested for-loops anyway, but something like flattening the inner loop into a return value. Nested for-loops aren’t uncommon in real-world code. And, I…am not sure what you are saying here. Loops are imperative constructs, not return values.
- brandmeyer 5y agoSince Python scopes lexical variables to the function instead of the block, `j` is in scope for every line of `... outer ...`. So de-denting the last line of inner doesn't trigger a NameError, even for new bindings which were introduced within `... inner ...`.