On 4/28/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
>
> Guido> You mean like this?
>
> if x > 0:
> ...normal case...
> elif y > 0:
> abnormal case...
> else:
> ...edge case...
>
> T
> Exaggeration in defense of elegance is no vice.
Maybe not, but it still sounds like BS to me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido> You mean like this?
if x > 0:
...normal case...
elif y > 0:
abnormal case...
else:
...edge case...
The salient example! If it's no accident that those conditions are
mutually exclusi
Michael Chermside wrote:
> if x == 1:|if condition_1:
> do_1() |y = 1
> elif x == 2: |elif condition_2:
> do_2() |y = 2
> elif x == 3: |elif condition_3:
> do_3() |y = 3
> else:
Guido writes:
> You mean like this?
>
> if x > 0:
>...normal case...
> elif y > 0:
> abnormal case...
> else:
> ...edge case...
>
> You have guts to call that bad style! :-)
Well, maybe, but this:
if x == 1:
do_number_1()
elif x == 2:
> Greg> 1) Repeating the name of the thing being switched on all the
> Greg> time, and the operator being used for comparison.
>
> What's worse, to my mind, is the not infrequent case where the thing
> being switched on or the operator changes. Sure, that's bad style,
> but sometimes you
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Two things are mildly annoying about if-elif chains as a
Greg> substitute for a switch statement:
Greg> 1) Repeating the name of the thing being switched on all the
Greg> time, and the operator being used for comparison.
Donovan Baarda wrote:
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed
benefits belong in implementation optimisations, not new bad syntax.
Two things are mildly annoying about if-elif chains as a
substitute for a switch statement:
1) Repeating the name of the thing being sw
On Mon, 2005-04-25 at 21:21 -0400, Brian Beck wrote:
> Donovan Baarda wrote:
> > Agreed. I don't find any switch syntaxes better than if/elif/else. Speed
> > benefits belong in implementation optimisations, not new bad syntax.
>
> I posted this 'switch' recipe to the Cookbook this morning, it save
On Mon, 2005-04-25 at 18:20 -0400, Jim Jewett wrote:
[...]
> If speed for a limited number of cases is the only advantage,
> then I would say it belongs in (at most) the implementation,
> rather than the language spec.
Agreed. I don't find any switch syntaxes better than if/elif/else. Speed
be
On 4/25/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Shannon -jj Behrens wrote:
> > On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >
> >>Fredrik Lundh wrote:
> >>
> >>>PS. a side effect of the for-in pattern is that I'm beginning to feel
> >>>that Python
> >>>might need a nice "switch" st
Shannon -jj Behrens wrote:
> On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>>Fredrik Lundh wrote:
>>
>>>PS. a side effect of the for-in pattern is that I'm beginning to feel
>>>that Python
>>>might need a nice "switch" statement based on dictionary lookups, so I can
>>>replace multiple ca
At 06:10 PM 04/21/2005 +0100, Michael Hudson wrote:
But the visitor pattern is pretty grim, really. It would be nice (tm)
to have something like:
match node in:
Assign(lhs=Var(_), rhs=_):
# lhs, rhs bound in here
Assign(lhs=Subscr(_,_), rhs=_):
# ditto
Assign(lhs=Slice(
On 4/21/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> Shannon -jj Behrens <[EMAIL PROTECTED]> writes:
>
> > On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >
> >> My use case for switch is that of a parser switching on tokens.
> >>
> >> mxTextTools applications would greatly benefit from
Samuele Pedroni <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
[pattern matching]
>>Can you post a quick summary of how you think this would work?
>>
>>
> Well, Python lists are used more imperatively and are not made up
> with cons cells, we have dictionaries which because of ordering
>
I wrote:
> Now the pattern matching is more interesting, but again, I'd need to
> see a proposed syntax for Python before I could begin to consider it.
> If I understand it properly, pattern matching in Haskell relies
> primarily on Haskell's excellent typing system, which is absent in
> Python.
N
Michael Hudson wrote:
Shannon -jj Behrens <[EMAIL PROTECTED]> writes:
On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
My use case for switch is that of a parser switching on tokens.
mxTextTools applications would greatly benefit from being able
to branch on tokens quickly. Currently, t
On 4/21/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Michael Chermside wrote:
> > Now the pattern matching is more interesting, but again, I'd need to
> > see a proposed syntax for Python before I could begin to consider it.
> > If I understand it properly, pattern matching in Haskell relies
> > p
Michael Chermside wrote:
Now the pattern matching is more interesting, but again, I'd need to
see a proposed syntax for Python before I could begin to consider it.
If I understand it properly, pattern matching in Haskell relies
primarily on Haskell's excellent typing system, which is absent in
Pyth
Andrew McGregor writes:
> I can post an alternative, inspired by this bit of Haskell
[...]
> The intent is that within the case, the bit before each : is a boolean
> expression, they're evaluated in order, and the following block is
> executed for the first one that evaluates to be True.
If we
I can post an alternative, inspired by this bit of Haskell (I've
deliberately left out the Haskell type annotation for this):
zoneOpts argv =
case getOpt Permute options argv of
(o,n,[]) -> return (o,n)
(_,_,errs) -> error errs
which could, in a future Python, look something like:
Shannon -jj Behrens <[EMAIL PROTECTED]> writes:
> On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>> My use case for switch is that of a parser switching on tokens.
>>
>> mxTextTools applications would greatly benefit from being able
>> to branch on tokens quickly. Currently, there's only
On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > PS. a side effect of the for-in pattern is that I'm beginning to feel
> > that Python
> > might need a nice "switch" statement based on dictionary lookups, so I can
> > replace multiple callbacks with a single loop body
23 matches
Mail list logo
