Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #104956 > unrolled thread

Case Statements

Back to article view | Back to comp.lang.python

Contents

  Case Statements jj0gen0info@gmail.com - 2016-03-15 13:46 -0700
    Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 23:11 +0000
    Re: Case Statements jj0gen0info@gmail.com - 2016-03-15 16:47 -0700
      Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-15 23:58 +0000
      Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 00:51 +0000
        Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 01:05 +0000
    Re: Case Statements jj0gen0info@gmail.com - 2016-03-15 18:55 -0700
      Re: Case Statements "Mario R. Osorio" <nimbiotics@gmail.com> - 2016-03-15 21:06 -0700
        Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 10:34 +0000
          Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-16 23:56 +1100
      Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 04:26 +0000
        Re: Case Statements Christian Gollwitzer <auriocus@gmx.de> - 2016-03-16 09:13 +0100
          Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 08:47 +0000
          Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 11:16 +0200
          Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 10:35 +0100
          Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 09:51 +0000
            Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 19:41 +0000
              Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 22:30 +0000
          Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 11:52 +0100
          Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 11:07 +0000
            Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 11:16 +0000
              Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 11:33 +0000
              Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 14:21 +0200
                Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 12:53 +0000
                  Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 16:31 +0200
                    Re: Case Statements BartC <bc@freeuk.com> - 2016-03-16 15:00 +0000
                      Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 19:07 +0200
                Re: Case Statements Rustom Mody <rustompmody@gmail.com> - 2016-03-20 01:01 -0700
                  Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-20 08:29 +0000
          Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-16 14:38 +0100
          Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 14:02 +0000
          Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 21:27 +0200
            Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:22 +0100
              Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-17 10:57 +0200
                Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 10:12 +0100
          Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 11:19 +1100
            Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 12:54 +1100
              Re: Case Statements Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-17 18:45 +1300
                Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 17:30 +1100
                  Re: Case Statements Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-18 18:59 +1300
                Re: Case Statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-17 17:29 +1100
                  Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 17:48 +1100
                    Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 21:53 +1100
                      Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 22:49 +1100
              Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 10:23 +0100
              Re: Case Statements Chris Angelico <rosuav@gmail.com> - 2016-03-17 20:55 +1100
            Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:36 +0100
          Re: Case Statements Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-17 09:38 +0100
    Re: Case Statements l0r0m0a0i0l@gmail.com - 2016-03-16 06:15 -0700
      Re: Case Statements Steven D'Aprano <steve@pearwood.info> - 2016-03-17 00:27 +1100
        Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 14:00 +0000
      Re: Case Statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-16 13:59 +0000
    Re: Case Statements l0r0m0a0i0l@gmail.com - 2016-03-16 07:21 -0700
      Re: Case Statements Marko Rauhamaa <marko@pacujo.net> - 2016-03-16 16:33 +0200

Page 1 of 3  [1] 2 3  Next page →

#104956 — Case Statements

Given that "Case Statements" are more compact and less redundant than a sequence of if-elif statements, and usually can contain embedded match lists:
Is there any chance future versions of Python will adopt a case structure?

Something like

select x
   case in [1,2,3,5,7,9]
   print ....
   case in [4,6,8]
   print ....
   case else
   print ....

Just a thought.

JJ

[toc] | [next] | [standalone]

#104961

On 15/03/2016 20:46, jj0gen0info@gmail.com wrote:
> Given that "Case Statements" are more compact and less redundant than a sequence of if-elif statements, and usually can contain embedded match lists:
> Is there any chance future versions of Python will adopt a case structure?
>
> Something like
>
> select x
>     case in [1,2,3,5,7,9]
>     print ....
>     case in [4,6,8]
>     print ....
>     case else
>     print ....
>
> Just a thought.
>
> JJ
>

Been suggested and rejected via 
https://www.python.org/dev/peps/pep-3103/ and 
https://www.python.org/dev/peps/pep-0275/.  The "Rejection Notice" 
section of the former states "A quick poll during my keynote 
presentation at PyCon 2007 shows this proposal has no popular support. I 
therefore reject it.".

See also http://c2.com/cgi/wiki?SwitchStatementsSmell

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104967

Thanks for the informative post.  I've read it and disagree with the rational, it places Python in a decided minority of the major languages.

https://en.wikipedia.org/wiki/Conditional_(computer_programming)#Case_and_switch_statements

See section "Choice system cross reference"

Thanks again for the reply

JJ

[toc] | [prev] | [next] | [standalone]

#104970

On 15/03/2016 23:47, jj0gen0info@gmail.com wrote:
>
> Thanks for the informative post.  I've read it and disagree with the rational, it places Python in a decided minority of the major languages.
>
> https://en.wikipedia.org/wiki/Conditional_(computer_programming)#Case_and_switch_statements
>
> See section "Choice system cross reference"
>
> Thanks again for the reply
>
> JJ
>

If the Python core developers have decided it isn't needed, as perhaps 
explained in my link about the "Switch Statement Code Smell", why worry 
about it?

If you really think you need one start here 
http://code.activestate.com/recipes/269708-some-python-style-switches/

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104977

On 15/03/2016 23:47, jj0gen0info@gmail.com wrote:
>
> Thanks for the informative post.  I've read it and disagree with the rational, it places Python in a decided minority of the major languages.

And this proposal (3103) was by the guy who invented the language!

Good thing he didn't have design-by-committee when he was putting it 
together.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#104979

On 16/03/2016 00:51, BartC wrote:
> On 15/03/2016 23:47, jj0gen0info@gmail.com wrote:
>>
>> Thanks for the informative post.  I've read it and disagree with the
>> rational, it places Python in a decided minority of the major languages.
>
> And this proposal (3103) was by the guy who invented the language!
>
> Good thing he didn't have design-by-committee when he was putting it
> together.
>

Did you miss or deliberately ignore my earlier:-

<quote>
The "Rejection Notice" section of the former states "A quick poll during 
my keynote presentation at PyCon 2007 shows this proposal has no popular 
support. I therefore reject it.".
</quote>

What do you not understand about "has no popular support", and this at 
the big Python annual event that is attended by numerous Python 
developers, including core developers, from all around the world?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104980

You have apparently mistaken me for someone who's worried.  I don't use Python, I was just curious as to why a construct that is found, not only to be useful in 95% of other languages, but is generally considered more flexible and readable than the if-elif, was missing in Python.  (your link "Switch Statement Code Smell" not withstanding)

Have a great day :)

[toc] | [prev] | [next] | [standalone]

#104986

On Tuesday, March 15, 2016 at 9:55:27 PM UTC-4, jj0ge...@gmail.com wrote:
> You have apparently mistaken me for someone who's worried.  I don't use Python, I was just curious as to why a construct that is found, not only to be useful in 95% of other languages, but is generally considered more flexible and readable than the if-elif, was missing in Python.  (your link "Switch Statement Code Smell" not withstanding)
> 
> Have a great day :)

Switch and case statements are such a waste of time that, in order to understand them you have to mentally use if/elseif/else/endif statements. Furthermore, the concepts of switch and case could not even exist without the notion of if/elseif/else/endif statements. Why then, add an extra level of complication??.

Go play with Java or Maybe C++. Have fun with their fancy if/elseif/else/endif statements oops, sorry, they call them switch and/or case statements.

Wish you the best and please lete us know if and when you have a deep fall through a breakeless case ... You must love debugging those ... they are fun, specially a 4:30am, with an hour and a half to deploy...

[toc] | [prev] | [next] | [standalone]

#105000

On 16/03/2016 04:06, Mario R. Osorio wrote:
> On Tuesday, March 15, 2016 at 9:55:27 PM UTC-4, jj0ge...@gmail.com wrote:
>> You have apparently mistaken me for someone who's worried.  I don't use Python, I was just curious as to why a construct that is found, not only to be useful in 95% of other languages, but is generally considered more flexible and readable than the if-elif, was missing in Python.  (your link "Switch Statement Code Smell" not withstanding)
>>
>> Have a great day :)
>
> Switch and case statements are such a waste of time that, in order to understand them you have to mentally use if/elseif/else/endif statements. Furthermore, the concepts of switch and case could not even exist without the notion of if/elseif/else/endif statements. Why then, add an extra level of complication??.

You're understanding them wrong then. Switch can be used like a 
'computed go to', where you execute the nth statement of a selection, or 
select the nth value of a list /without needing to evaluate any of the 
others/.

Or it can be more general, where each statement or value in the 
selection has a corresponding 'case', and it will directly execute or 
select it according to the switch expression:

switch d:
case 1:
    n = p//8
    pal = 2
case 4:
    n = p//2
    pal=16
case 8:
    n = p
    pal = 256
case 16:
    n = p*2
case 24:
    n = p*3
case 32:
    n = p*4
    a = 1
else:
    raise ...

Sure, there are half a dozen ways of writing such code. But you don't 
want to think of it in terms if-elif where you first have to test all 
the other cases when d is 32, and have to keep writing 'd==' over and over.

And you don't want to take this straightforward bit of code and spread 
it over many functions and classes and methods; it's all here.

(BTW why does Python have 'elif' when if-else is all that is really needed?)

> Go play with Java or Maybe C++. Have fun with their fancy if/elseif/else/endif statements oops, sorry, they call them switch and/or case statements.
>
> Wish you the best and please lete us know if and when you have a deep fall through a breakeless case ...

C got those badly wrong. (It got a lot of things wrong.) That doesn't 
mean that switch, properly implemented, is bad.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#105016

On Wed, 16 Mar 2016 09:34 pm, BartC wrote:


> (BTW why does Python have 'elif' when if-else is all that is really
> needed?)

To save indentation.


if condition:
    block
else:
    if other:
        block
    else:
        if third:
            block
        else:
            block


versus:

if condition:
    block
elif other:
    block
elif third:
    block
else:
    block


Python could have spelled "elif" as "else if", but that's just a matter of
spelling. Either way, the important thing is that the else-if/elif keeps
the same indentation as the if.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#104987

On 16/03/2016 01:55, jj0gen0info@gmail.com wrote:
> You have apparently mistaken me for someone who's worried.  I don't use Python, I was just curious as to why a construct that is found, not only to be useful in 95% of other languages, but is generally considered more flexible and readable than the if-elif, was missing in Python.  (your link "Switch Statement Code Smell" not withstanding)
>
> Have a great day :)
>

So you would rather write something like:-

switch (x):
   case COW:
     moo()
     break

   case DUCK:
     quack()
     break

   default IDUNNO:
     panic()

than:-

x.makeNoise()

?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104992

Am 16.03.16 um 05:26 schrieb Mark Lawrence:
> So you would rather write something like:-
>
> switch (x):
>    case COW:
>      moo()
>      break
>
>    case DUCK:
>      quack()
>      break
>
>    default IDUNNO:
>      panic()
>
> than:-
>
> x.makeNoise()

No sane person would do that. But just because you selected the worst 
possible semantics (fallthrough/break) and the worst posible use case 
(simulating polymorphism) doesn't mean that switches have no use. Code 
like the above was used a lot in early GUI toolkits for C - Motif and 
the Windows C API, for instance, use a gigantic switch to decide upon 
incoming events. Now the strange statement in the switch discussion 
makes sense:

"Typically, similar switch statements are scattered throughout a 
program. If you add or remove a clause in one switch, you often have to 
find and repair the others too."

That happens indeed if one were to simulate polymorphism using switch 
statements, but not for other cases.

In Python, you need to go the other way round, you don't have a switch, 
but you can simulate it via function tables or polymorphism.
The difference between a switch and its simulation via function pointer 
tables etc. is the scope. In a true switch statement, the code blocks 
access the same variables. You can't truly simulate an if statement in 
Python, if it were missing:

 >>> def hi():
...  print "hi"
...
 >>> def yu():
...  print "yu"
...
 >>> hi() if 1>2 else yu()
yu
 >>> hi() if 2>1 else yu()
hi

This gives you, in principal, an if-then-else statement back. But you 
can't do something like

if 1>2:
   a=3
else:
   b=2

Same with switch. You can use a hash table etc. to simulate switches, 
but only if the codeblocks are independent. Otherwise, if-elif chains 
are the way to go. Command line parsing is a case where switch 
statements are often used, e.g. in shell scripts.

	Christian

[toc] | [prev] | [next] | [standalone]

#104993

On 16/03/2016 08:13, Christian Gollwitzer wrote:
> Am 16.03.16 um 05:26 schrieb Mark Lawrence:
>> So you would rather write something like:-
>>
>> switch (x):
>>    case COW:
>>      moo()
>>      break
>>
>>    case DUCK:
>>      quack()
>>      break
>>
>>    default IDUNNO:
>>      panic()
>>
>> than:-
>>
>> x.makeNoise()
>
> No sane person would do that. But just because you selected the worst
> possible semantics (fallthrough/break) and the worst posible use case
> (simulating polymorphism) doesn't mean that switches have no use. Code
> like the above was used a lot in early GUI toolkits for C - Motif and
> the Windows C API, for instance, use a gigantic switch to decide upon
> incoming events. Now the strange statement in the switch discussion
> makes sense:

I've never said that switches have no use. As the powers to be have 
decreed that they're not going into Python, and I fully agree with that 
decision, I just wish people would shut up about them, but the issue 
keeps cropping up.

>
> "Typically, similar switch statements are scattered throughout a
> program. If you add or remove a clause in one switch, you often have to
> find and repair the others too."
>
> That happens indeed if one were to simulate polymorphism using switch
> statements, but not for other cases.
>
> In Python, you need to go the other way round, you don't have a switch,
> but you can simulate it via function tables or polymorphism.
> The difference between a switch and its simulation via function pointer
> tables etc. is the scope. In a true switch statement, the code blocks
> access the same variables. You can't truly simulate an if statement in
> Python, if it were missing:

I've no idea at all what you mean by the above.

>
>  >>> def hi():
> ...  print "hi"
> ...
>  >>> def yu():
> ...  print "yu"
> ...
>  >>> hi() if 1>2 else yu()
> yu
>  >>> hi() if 2>1 else yu()
> hi
>
> This gives you, in principal, an if-then-else statement back. But you
> can't do something like
>
> if 1>2:
>    a=3
> else:
>    b=2

The above appears to have crept into Python when you weren't looking.

C:\Users\Mark\Documents\MyPython>py -3
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> if 1>2:
...   a=2
... else:
...   b=3
...
 >>> a
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
 >>> b
3

>
> Same with switch. You can use a hash table etc. to simulate switches,
> but only if the codeblocks are independent. Otherwise, if-elif chains
> are the way to go. Command line parsing is a case where switch
> statements are often used, e.g. in shell scripts.

I've seen at least six different ways of simulating switches, so those 
people who want them, can have them.  if-elif chains are not likely to 
kill any Python programmer.

I have no interest what other languages use switch/case statements for, 
as we've on the PYTHON mailing list.

>
>      Christian


-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#104994

Christian Gollwitzer <auriocus@gmx.de>:

> That happens indeed if one were to simulate polymorphism using switch
> statements, but not for other cases.

There are not many other cases. Decoding is the only generally valid
case I can think of.

> In Python, you need to go the other way round, you don't have a
> switch, but you can simulate it via function tables or polymorphism.

Let's look at one case that I routinely implement using switch
statements in C: finite state machines. The reaction of an entity to a
stimulus depends on the state of the entity. That clearly is a case of
polymorphism.

There there is the reaction to system errors. However, there usually are
not so many options to consider that one would yearn for a switch
statement:

    try:
        bytes = self.tcpconn.read()
    except socket.error as e:
        if e.errno == errno.EAGAIN:
            raise incomplete
        raise
                                                        
What other cases do you have in mind?

> The difference between a switch and its simulation via function
> pointer tables etc. is the scope. In a true switch statement, the code
> blocks access the same variables. You can't truly simulate an if
> statement in Python [...] Same with switch. You can use a hash table
> etc. to simulate switches, but only if the codeblocks are independent.

Such assignments are usually done to an object's data attributes.
Closures have "self" accessible to them so they can naturally update
"self.x" in the polymorphic methods.

> Same with switch. You can use a hash table etc. to simulate switches,
> but only if the codeblocks are independent. Otherwise, if-elif chains
> are the way to go. Command line parsing is a case where switch
> statements are often used, e.g. in shell scripts.

You have the same thing in C:

     if (!strcmp(arg, "now"))
         do_it_now();
     else if (!strcmp(arg, "soon"))
         do_it_now();
     else if  (!strcmp(arg, "later"))
         do_it_later();
     else complain();


Marko

[toc] | [prev] | [next] | [standalone]

#104996

Op 16-03-16 om 09:47 schreef Mark Lawrence:
>
>>
>> Same with switch. You can use a hash table etc. to simulate switches,
>> but only if the codeblocks are independent. Otherwise, if-elif chains
>> are the way to go. Command line parsing is a case where switch
>> statements are often used, e.g. in shell scripts.
>
> I've seen at least six different ways of simulating switches, so those
> people who want them, can have them.  if-elif chains are not likely to
> kill any Python programmer.
>
> I have no interest what other languages use switch/case statements
> for, as we've on the PYTHON mailing list.

There once were multiple ways to simulate a conditional expression.
And it was generally thought that using if else statements instead
of a conditional expression was unlikely to kill any Python programmer.

But then one of the core developers was bitten by a nasty bug because
he was using one of those constructs that simulated a conditional
expression and soon enough Python had a conditional expression.

So I guess those who would like a case statement in Python can
only hope a core developer gets bitten by a nasty bug while using
one of those ways of simulating switches.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#104997

On 16/03/2016 09:35, Antoon Pardon wrote:
> Op 16-03-16 om 09:47 schreef Mark Lawrence:
>>
>>>
>>> Same with switch. You can use a hash table etc. to simulate switches,
>>> but only if the codeblocks are independent. Otherwise, if-elif chains
>>> are the way to go. Command line parsing is a case where switch
>>> statements are often used, e.g. in shell scripts.
>>
>> I've seen at least six different ways of simulating switches, so those
>> people who want them, can have them.  if-elif chains are not likely to
>> kill any Python programmer.
>>
>> I have no interest what other languages use switch/case statements
>> for, as we've on the PYTHON mailing list.
>
> There once were multiple ways to simulate a conditional expression.
> And it was generally thought that using if else statements instead
> of a conditional expression was unlikely to kill any Python programmer.
>
> But then one of the core developers was bitten by a nasty bug because
> he was using one of those constructs that simulated a conditional
> expression and soon enough Python had a conditional expression.
>
> So I guess those who would like a case statement in Python can
> only hope a core developer gets bitten by a nasty bug while using
> one of those ways of simulating switches.
>

So that core developers can waste their time putting something into the 
language that we've done without for 25 years, yes, that strikes me as 
extremely worthwhile.  Of course the change is actually trivial, as 
BartC has all ready pointed out. The work involved is shown here 
https://mail.python.org/pipermail/python-dev/2006-June/065827.html

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#105061

On 16/03/2016 09:51, Mark Lawrence wrote:
> On 16/03/2016 09:35, Antoon Pardon wrote:

>> So I guess those who would like a case statement in Python can
>> only hope a core developer gets bitten by a nasty bug while using
>> one of those ways of simulating switches.
>>
>
> So that core developers can waste their time putting something into the
> language that we've done without for 25 years, yes, that strikes me as
> extremely worthwhile.


I've noticed that Python doesn't appear to have a way of putting 
separators into numeric literals. (Or if it does, I've no idea how). 
That means being able to write:

a = 1'000'000
b =   239_288
c = 0x7FFF`FFFF`FFFF`FFFF

depending on what separator is used. Despite waiting for it for 25 
years, would that be worthwhile or not? (And if not, why not? And if it 
is, perhaps other things can be too.)

> Of course the change is actually trivial,

The above really is trivial (to anyone already familiar with the 
workings of the byte-code compiler).

> as
> BartC has all ready pointed out. The work involved is shown here
> https://mail.python.org/pipermail/python-dev/2006-June/065827.html

That article appears to try to do without using a new switch byte-code, 
as the author doesn't see the point. My code to implement a 'switch' 
byte-code (for integer expression and constant integer case-expressions) 
is below.

Not shown is the support needed in the byte-code compiler (about 300 
lines in my case as it's a bit fiddly, but it's not a run-time cost).

For a Python version, it might be an idea to make use of the convention 
for constants (all-caps), then a streamlined switch could be on the cards.

global function k_switch:ref void =
     int index,n,lower

     n := getopnda
     lower := getopndb

     case sptr^.tag
     when tint,ttype then
     else
     	pcerror("switch not int")
     esac

     index:=(sptr++)^.value-lower

     if u32(index)>=u32(n) then        # out of range
     	return ref int((pcptr+n*2+4)^)
     else
     	return ref int((pcptr+index*2+4)^)
     fi
end


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#105062

On 16/03/2016 21:43, Mark Lawrence wrote:
> On 16/03/2016 19:41, BartC wrote:

>> That article appears to try to do without using a new switch byte-code,
>> as the author doesn't see the point. My code to implement a 'switch'
>> byte-code (for integer expression and constant integer case-expressions)
>> is below.

> Job done then.  Raise an issue on the bug tracker and the extremely
> simple task of having a switch/case statement in Python is solved.  How
> the dumbo core developers didn't see this in the first place I'll just
> never know.

The technical side is not the problem. But the language, the size of it, 
the organisation behind it, and the myriad implementations, is a monster.

I'm not interested in battling with that or all the people who don't 
want change. Plus the problems of keeping backwards compatibility.

But if you're talking about the code to implement 'switch', then yes it 
can be that simple. Although it seems no one is going to agree on the 
exact form it would take.

(If I wanted to code in Python, and really wanted a switch statement, 
then I would do a syntax translator, which I have already experimented 
with in the past.

So I would write code in 'Python+switch', and translate to normal Python 
being running it. Then I get some of the benefits immediately. What I 
don't get however is the performance that could go with it if it was a 
real part of the language.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#105003

Op 16-03-16 om 10:51 schreef Mark Lawrence:
> On 16/03/2016 09:35, Antoon Pardon wrote:
>> Op 16-03-16 om 09:47 schreef Mark Lawrence:
>>>
>>>>
>>>> Same with switch. You can use a hash table etc. to simulate switches,
>>>> but only if the codeblocks are independent. Otherwise, if-elif chains
>>>> are the way to go. Command line parsing is a case where switch
>>>> statements are often used, e.g. in shell scripts.
>>>
>>> I've seen at least six different ways of simulating switches, so those
>>> people who want them, can have them.  if-elif chains are not likely to
>>> kill any Python programmer.
>>>
>>> I have no interest what other languages use switch/case statements
>>> for, as we've on the PYTHON mailing list.
>>
>> There once were multiple ways to simulate a conditional expression.
>> And it was generally thought that using if else statements instead
>> of a conditional expression was unlikely to kill any Python programmer.
>>
>> But then one of the core developers was bitten by a nasty bug because
>> he was using one of those constructs that simulated a conditional
>> expression and soon enough Python had a conditional expression.
>>
>> So I guess those who would like a case statement in Python can
>> only hope a core developer gets bitten by a nasty bug while using
>> one of those ways of simulating switches.
>>
>
> So that core developers can waste their time putting something into
> the language that we've done without for 25 years, yes, that strikes
> me as extremely worthwhile.

Do you think python should stop progressing? Because all progress
python wil make, will be done by putting something in the language
we've done without for 25 years.

That we have done without doesn't contradict it can be useful to have.

-- 
Antoon.

[toc] | [prev] | [next] | [standalone]

#105004

On 16/03/2016 10:52, Antoon Pardon wrote:
> Op 16-03-16 om 10:51 schreef Mark Lawrence:
>> On 16/03/2016 09:35, Antoon Pardon wrote:
>>> Op 16-03-16 om 09:47 schreef Mark Lawrence:
>>>>
>>>>>
>>>>> Same with switch. You can use a hash table etc. to simulate switches,
>>>>> but only if the codeblocks are independent. Otherwise, if-elif chains
>>>>> are the way to go. Command line parsing is a case where switch
>>>>> statements are often used, e.g. in shell scripts.
>>>>
>>>> I've seen at least six different ways of simulating switches, so those
>>>> people who want them, can have them.  if-elif chains are not likely to
>>>> kill any Python programmer.
>>>>
>>>> I have no interest what other languages use switch/case statements
>>>> for, as we've on the PYTHON mailing list.
>>>
>>> There once were multiple ways to simulate a conditional expression.
>>> And it was generally thought that using if else statements instead
>>> of a conditional expression was unlikely to kill any Python programmer.
>>>
>>> But then one of the core developers was bitten by a nasty bug because
>>> he was using one of those constructs that simulated a conditional
>>> expression and soon enough Python had a conditional expression.
>>>
>>> So I guess those who would like a case statement in Python can
>>> only hope a core developer gets bitten by a nasty bug while using
>>> one of those ways of simulating switches.
>>>
>>
>> So that core developers can waste their time putting something into
>> the language that we've done without for 25 years, yes, that strikes
>> me as extremely worthwhile.
>
> Do you think python should stop progressing? Because all progress
> python wil make, will be done by putting something in the language
> we've done without for 25 years.
>
> That we have done without doesn't contradict it can be useful to have.
>

Raise the item on the python-ideas mailing list for the umpteenth time 
then, and see how far you get.  The last attempt that I can find starts 
here 
https://mail.python.org/pipermail/python-ideas/2014-April/027665.html. 
The BDFL reply at 
https://mail.python.org/pipermail/python-ideas/2014-April/027667.html was:-

<quote>
I don't want to discourage you too much, but I think that adding a 
switch statement comes *very* low on the list of improvements we would 
like to make in Python 3.5.

We should probably focus on speed (or aspects of it, like startup),
language features that help porting Python 2 code to it (e.g. bytes
formatting), and things that improve the user experience of getting 
started with Python on a new machine (e.g. pip/venv). Or perhaps stdlib 
issues like an asyncio-infused variation of WSGI.

I've probably missed a few focus areas, but I still very much doubt 
we'll be adding a switch statement -- it's a "sexy" language design 
issue (like anonymous functions) but that's not what will help Python 
compete.
</quote>

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web