4 ms·

Given that Python has "break" as a keyword and "Explicit is better than implicit", I thought it was Pythonic to have it this way.

laurentlb 8y ago
If the code implicitly executes the next block (unless there's a `break`), I don't think it's better. * Option 1. To be more explicit, require that each block ends with break or continue. * Option 2. Use continue (or fallthrough as in Go) to execute the next block. Otherwise, it exits the block. * Option 3. Support neither continue, nor break. Each block is independent from each other and there's no way to continue to the next block. I'd personally go with Option 3. This means that break/continue can be used inside the switch to break/continue an enclosing loop. I don't think the missing feature is a big miss anyway.
- aroberge 8y ago
  To implement Option 3, it most likely suffices to remove any mention of self.fall in https://github.com/aroberge/experimental/blob/master/experimental/transformers/switch_statement.py#L50 https://github.com/aroberge/experimental/blob/master/experim...
- milesvp 8y ago
  Let's not forget that for C style switch statements, the implicit fallthrough is often sited as a bug (though it looks to have been influenced by fortran's computed GOTO, so certainly there was earlier precedent). I will tell you having done over a decade of maintenance programming. The absolute worse thing you can do is have implicit fallthrough. Bugs of omission are the hardest to fix, since it's unclear what the original intended behavior was supposed to be, let alone whether the code is actually doing what it's supposed to. Basically there are three things you have to figure out when working with other's code, you have to figure out: what the code is doing, what the code is supposed to be doing, and what the original author thought the code was doing. What often happens, is you find a piece of code that looks like it's a bug, but it turns out that there's some edge case that requires a piece of code to look like it does (and maybe the current bug is less severe than the edge case that it deals with). Something like a missing break can be one of the hardest things to reason about in code, because it's unclear if the author knew something about each case than me, or if they just forgot to put one. Personally, I support neither continue, nor break. Code duplication is not as big a sin as most programmers feel it is. But I can appreciate an explicit continue, since it's a useful enough construct for people to keep implementing fallthrough. I also might vote for a new keyword other than continue, since continue fells slightly overloaded in this context.
ant6n 8y ago
Well, break is an explicit statement that will force execution to continue after the current block. I.e. it breaks out of the current list of of statements. I'd argue that flowing through cases is a very implicit behavior. It would be the only control-flow behavior in Python where execution continues at a sibling block. I think it kind of follows from the way switch statements used to be implemented using jump-tables in C, and is pretty surprising for people who learn the language today (i.e. those who didn't learn C by first learning assembler). I'd argue that flow-through should be made explicit, e.g. using "continue" -- if it's a necessary feature, which is yet another discussion.

laurentlb 8y ago

If the code implicitly executes the next block (unless there's a `break`), I don't think it's better. * Option 1. To be more explicit, require that each block ends with break or continue. * Option 2. Use continue (or fallthrough as in Go) to execute the next block. Otherwise, it exits the block. * Option 3. Support neither continue, nor break. Each block is independent from each other and there's no way to continue to the next block. I'd personally go with Option 3. This means that break/continue can be used inside the switch to break/continue an enclosing loop. I don't think the missing feature is a big miss anyway.

aroberge 8y ago
To implement Option 3, it most likely suffices to remove any mention of self.fall in https://github.com/aroberge/experimental/blob/master/experimental/transformers/switch_statement.py#L50 https://github.com/aroberge/experimental/blob/master/experim...
milesvp 8y ago
Let's not forget that for C style switch statements, the implicit fallthrough is often sited as a bug (though it looks to have been influenced by fortran's computed GOTO, so certainly there was earlier precedent). I will tell you having done over a decade of maintenance programming. The absolute worse thing you can do is have implicit fallthrough. Bugs of omission are the hardest to fix, since it's unclear what the original intended behavior was supposed to be, let alone whether the code is actually doing what it's supposed to. Basically there are three things you have to figure out when working with other's code, you have to figure out: what the code is doing, what the code is supposed to be doing, and what the original author thought the code was doing. What often happens, is you find a piece of code that looks like it's a bug, but it turns out that there's some edge case that requires a piece of code to look like it does (and maybe the current bug is less severe than the edge case that it deals with). Something like a missing break can be one of the hardest things to reason about in code, because it's unclear if the author knew something about each case than me, or if they just forgot to put one. Personally, I support neither continue, nor break. Code duplication is not as big a sin as most programmers feel it is. But I can appreciate an explicit continue, since it's a useful enough construct for people to keep implementing fallthrough. I also might vote for a new keyword other than continue, since continue fells slightly overloaded in this context.

ant6n 8y ago

Well, break is an explicit statement that will force execution to continue after the current block. I.e. it breaks out of the current list of of statements. I'd argue that flowing through cases is a very implicit behavior. It would be the only control-flow behavior in Python where execution continues at a sibling block. I think it kind of follows from the way switch statements used to be implemented using jump-tables in C, and is pretty surprising for people who learn the language today (i.e. those who didn't learn C by first learning assembler). I'd argue that flow-through should be made explicit, e.g. using "continue" -- if it's a necessary feature, which is yet another discussion.