Another idea for a switch statement
Hello all. I read PEP 275 but I don't like the syntax of examples. What do you think about something like this? if x case value1 : [...] case value2 : [...] case value3 : [...] else : [...]
Generally, I don't think much of switch statements as they appear in C/C++/Java. Those sorts of things can only switch on trivial data (i.e. ints, chars, strings in C#) and go against the OO grain of the language: They encourage people to store special "behavioral flags" inside objects to modify their behavior with switches, rather than using proper OO inheritance/subclassing. Furthermore, they don't really provide much of a syntactic advantage over chained elifs, or using a delegate dict (which has the advantage of being programmatically modifiable. Both of those are far more flexible and powerful. Unless we're going all the way to F#/Haskell/Scala style 'match' statements (which are completely awesome), there really isn't much point in them. -Haoyi On Tue, Oct 11, 2011 at 6:15 PM, Chris Rebert <pyideas@rebertia.com> wrote:
On Wed, Oct 12, 2011 at 8:15 AM, Chris Rebert <pyideas@rebertia.com> wrote:
Indeed, they were not. PEP 3103 elaborates on the wide range of design decisions that need to be made in crafting a switch statement for Python. For most of them, all of the available options have some significant downsides. Add in the fact that the desire to use a long if/elif chain in Python often suggests a deeper architectural problem in the relevant code (usually something like "when using Python, write Python, not C"), the idea of adding a new and complicated construct to the language for such a niche use case doesn't garner much support. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Generally, I don't think much of switch statements as they appear in C/C++/Java. Those sorts of things can only switch on trivial data (i.e. ints, chars, strings in C#) and go against the OO grain of the language: They encourage people to store special "behavioral flags" inside objects to modify their behavior with switches, rather than using proper OO inheritance/subclassing. Furthermore, they don't really provide much of a syntactic advantage over chained elifs, or using a delegate dict (which has the advantage of being programmatically modifiable. Both of those are far more flexible and powerful. Unless we're going all the way to F#/Haskell/Scala style 'match' statements (which are completely awesome), there really isn't much point in them. -Haoyi On Tue, Oct 11, 2011 at 6:15 PM, Chris Rebert <pyideas@rebertia.com> wrote:
On Wed, Oct 12, 2011 at 8:15 AM, Chris Rebert <pyideas@rebertia.com> wrote:
Indeed, they were not. PEP 3103 elaborates on the wide range of design decisions that need to be made in crafting a switch statement for Python. For most of them, all of the available options have some significant downsides. Add in the fact that the desire to use a long if/elif chain in Python often suggests a deeper architectural problem in the relevant code (usually something like "when using Python, write Python, not C"), the idea of adding a new and complicated construct to the language for such a niche use case doesn't garner much support. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Chris Rebert -
Haoyi Li -
Lucas Malor -
Nick Coghlan