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

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

(test) ? a:b

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

Contents

  (test) ? a:b "ast" <nomail@invalid.com> - 2014-10-22 10:29 +0200
    Re: (test) ? a:b buscacio@gmail.com - 2014-10-22 02:05 -0700
      Re: (test) ? a:b "ast" <nomail@invalid.com> - 2014-10-22 11:14 +0200
        Re: (test) ? a:b Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-22 12:45 +0100
          Re: (test) ? a:b "ast" <nomail@invalid.com> - 2014-10-27 09:01 +0100
        Re: (test) ? a:b Michael Torrie <torriem@gmail.com> - 2014-10-22 11:16 -0600
          Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-23 11:44 +1100
      Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-22 20:15 +1100
      Re: (test) ? a:b Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-22 10:16 +0100
      Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-22 20:27 +1100
        Re: (test) ? a:b Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-10-23 16:46 +1300
          Re: (test) ? a:b MRAB <python@mrabarnett.plus.com> - 2014-10-23 11:12 +0100
            Re: (test) ? a:b "ast" <nomail@invalid.com> - 2014-10-24 08:38 +0200
          Re: (test) ? a:b Michael Torrie <torriem@gmail.com> - 2014-10-25 19:04 -0600
            Re: (test) ? a:b Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-10-27 22:04 +1300
          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-26 12:20 +1100
          Re: (test) ? a:b Michael Torrie <torriem@gmail.com> - 2014-10-25 21:05 -0600
      Re: (test) ? a:b Ned Batchelder <ned@nedbatchelder.com> - 2014-10-22 07:30 -0400
        Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-22 14:41 +0300
        Re: (test) ? a:b Rustom Mody <rustompmody@gmail.com> - 2014-10-22 06:16 -0700
          Re: (test) ? a:b "BartC" <bc@freeuk.com> - 2014-10-22 19:08 +0100
            Re: (test) ? a:b Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-22 19:55 -0400
              Re: (test) ? a:b "BartC" <bc@freeuk.com> - 2014-10-23 11:50 +0100
                Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-23 16:44 +0300
                  Re: (test) ? a:b Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-23 08:24 -0600
                  Re: (test) ? a:b Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-10-23 16:41 +0200
                    Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-23 19:20 +0300
                  Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-24 19:38 +1100
                    Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-24 19:45 +1100
                    Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-24 12:37 +0300
                      Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-25 00:07 +1100
                        Re: (test) ? a:b Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-24 12:22 -0600
                          Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-24 21:46 +0300
                    Re: (test) ? a:b Dan Stromberg <drsalists@gmail.com> - 2014-10-24 10:20 -0700
                      Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-24 20:58 +0000
                        Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-25 00:02 +0300
                        Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-25 16:03 +1100
                          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-25 16:25 +1100
                          Re: (test) ? a:b Ned Batchelder <ned@nedbatchelder.com> - 2014-10-25 07:58 -0400
                          Re: (test) ? a:b Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-25 07:53 -0600
                          Re: (test) ? a:b Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-25 14:11 -0400
                          Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-25 19:49 +0000
                          Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-26 07:45 +1100
                            Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-26 11:10 +1100
                              Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-26 12:03 +1100
                                Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-26 15:15 +1100
                                  Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-26 15:34 +1100
                                  Re: (test) ? a:b Terry Reedy <tjreedy@udel.edu> - 2014-10-26 17:12 -0400
                                  Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-27 11:38 +1100
                                  Re: (test) ? a:b MRAB <python@mrabarnett.plus.com> - 2014-10-27 01:40 +0000
                                  Re: (test) ? a:b Rustom Mody <rustompmody@gmail.com> - 2014-10-26 19:19 -0700
                              Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-26 12:10 +1100
                              Re: (test) ? a:b Joshua Landau <joshua@landau.ws> - 2014-10-27 01:55 +0000
                              Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-27 13:28 +1100
                                Re: (test) ? a:b Rustom Mody <rustompmody@gmail.com> - 2014-10-26 19:38 -0700
                              Re: (test) ? a:b Joshua Landau <joshua@landau.ws> - 2014-10-27 02:43 +0000
                              Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-27 13:56 +1100
                          Re: (test) ? a:b Dan Stromberg <drsalists@gmail.com> - 2014-10-25 15:34 -0700
                          Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-26 10:53 +1100
                          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-26 11:01 +1100
                          Re: (test) ? a:b Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-26 01:09 +0100
                          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-26 11:13 +1100
            Re: (test) ? a:b Vito De Tullio <vito.detullio@gmail.com> - 2014-10-23 06:55 +0200
        Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-23 03:28 +1100
          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-23 03:40 +1100
          Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-22 18:03 +0000
          Re: (test) ? a:b Matthew Ruffalo <mmr15@case.edu> - 2014-10-22 14:27 -0400
          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-23 05:30 +1100
          Re: (test) ? a:b Ned Batchelder <ned@nedbatchelder.com> - 2014-10-22 16:11 -0400
      Re: (test) ? a:b Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-22 12:41 +0100
        Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-22 15:12 +0000
          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-23 02:18 +1100
            Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-22 15:24 +0000
      Re: (test) ? a:b Dan Stromberg <drsalists@gmail.com> - 2014-10-22 09:09 -0700
    Re: (test) ? a:b Tobiah <toby@tobiah.org> - 2014-10-24 10:23 -0700
      Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-25 04:27 +1100
        Re: (test) ? a:b Tobiah <toby@tobiah.org> - 2014-10-24 11:31 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#79464

"Rustom Mody" <rustompmody@gmail.com> wrote in message 
news:7d2ea3c1-504e-4f5c-8338-501b1483df38@googlegroups.com...
> On Wednesday, October 22, 2014 5:01:08 PM UTC+5:30, Ned Batchelder wrote:
>> On 10/22/14 5:05 AM, buscacio wrote:
>> > Em quarta-feira, 22 de outubro de 2014 06h29min55s UTC-2, ast 
>> > escreveu:
>> >> Hello
>> >> Is there in Python something like:
>> >> j = (j >= 10) ? 3 : j+1;
>> >> as in C language ?
>> >> thx
>> > without not:
>> > j = [j+1, 3][j>=10]
>> > with not:
>> > j = [3, j+1][not (j>=10)]
>
>> Why on earth would you recommend this outdated hack, when there's a true
>> conditional operator?
>
>
> To learn a bit about the interchangeability of control and data 
> structures?
>
> [Just playing devil's advocate]

But it doesn't do the same thing.

Comparing:

 x = cond ? f() : g();       # C version

with

 x = [f(), g()] [cond]

the latter evaluates both f() and g() instead of just one. Apart from being 
inefficient, it can have unintended side-effects.

-- 
Bartc

 

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

#79484

On Wed, 22 Oct 2014 19:08:40 +0100, "BartC" <bc@freeuk.com> declaimed the
following:

>
>Comparing:
>
> x = cond ? f() : g();       # C version
>
>with
>
> x = [f(), g()] [cond]
>
>the latter evaluates both f() and g() instead of just one. Apart from being 
>inefficient, it can have unintended side-effects.

	Ah, but what would

	x = [f, g][cond]()

produce?
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#79510

"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message 
news:mailman.15097.1414022143.18130.python-list@python.org...
> On Wed, 22 Oct 2014 19:08:40 +0100, "BartC" <bc@freeuk.com> declaimed the
> following:
>
>>
>>Comparing:
>>
>> x = cond ? f() : g();       # C version
>>
>>with
>>
>> x = [f(), g()] [cond]

(Should probably be x = [g(), f()] [cond])

>>
>>the latter evaluates both f() and g() instead of just one. Apart from 
>>being
>>inefficient, it can have unintended side-effects.
>
> Ah, but what would
>
> x = [f, g][cond]()
>
> produce?

It will select f or g (which should refer to functions), and call one of 
those depending on cond. That's not a problem.

The problem is it will still evaluate both f and g, even if they are simple 
in this case, and construct a list which is then indexed by cond. (Although 
in this case a bytecode compiler might be smart enough to avoid constructing 
the list, it can't do that with my example because the code might depend on 
both those options being evaluated.)

-- 
Bartc 

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

#79515

"BartC" <bc@freeuk.com>:

>> Ah, but what would
>>
>> x = [f, g][cond]()
>>
>> produce?
>
> It will select f or g (which should refer to functions), and call one of
> those depending on cond. That's not a problem.
>
> The problem is it will still evaluate both f and g,

That's not really the problem. The problem is in readability.

However, the "[f, g][cond]()" technique is how pure lambda calculus
implements conditional branching so it is interesting in its own right.
IOW, you can do "short-circuiting" in purely functional programming:

    j = j + 1 if j < 10 else 3

    <=>

    j = (lambda: 3, lambda: j + 1)[j < 10]()


Marko

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

#79521

On Thu, Oct 23, 2014 at 7:44 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> However, the "[f, g][cond]()" technique is how pure lambda calculus
> implements conditional branching so it is interesting in its own right.

I wasn't aware that lambda calculus had lists and indexing built in.

> IOW, you can do "short-circuiting" in purely functional programming:
>
>     j = j + 1 if j < 10 else 3
>
>     <=>
>
>     j = (lambda: 3, lambda: j + 1)[j < 10]()

The implementation given by Wikipedia (and translated into Python by me) is:

>>> true = lambda x: lambda y: x
>>> false = lambda x: lambda y: y
>>> ifthenelse = lambda p: lambda a: lambda b: p(a)(b)
>>> ifthenelse(true)(1)(2)
1
>>> ifthenelse(false)(1)(2)
2

For demonstration purposes I used Python ints as the branches rather
than actual lambda calculus constructs, but this shows how selection
can be done using only lambda abstractions and applications.

In any case I don't see how this relates to the "[f, g][cond]()"
technique of Python, unless you just meant the general approach of
first selecting a function and then applying it. In that sense though,
the ternary operator does the same thing; the application is just done
invisibly by the language in the form of evaluating an expression as
opposed to explicitly applying a function.

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

#79526

Marko Rauhamaa <marko@pacujo.net> writes:

> "BartC" <bc@freeuk.com>:

>>> x = [f, g][cond]()

>> It will select f or g (which should refer to functions), and call one of
>> those depending on cond. That's not a problem.
>>
>> The problem is it will still evaluate both f and g,
>
> That's not really the problem. The problem is in readability.

Readability is in the eye of the beholder. The evaluation is the central
concern here.

> However, the "[f, g][cond]()" technique is how pure lambda calculus
> implements conditional branching so it is interesting in its own
> right.

Yes, but lambda calculus constructs have no meaning without an
evaluation strategy ("reduction" strategy in lambda calculs parlance).

> IOW, you can do "short-circuiting" in purely functional programming:
>
>     j = j + 1 if j < 10 else 3
>     <=>
>     j = (lambda: 3, lambda: j + 1)[j < 10]()

This is just a way to delay evaluation *of the potential results*, i.e.,
instill a bit of lazyness. One could object that, again, both
expressions in the tuple have been evaluated (building two lambdas),
only one of which is finally called. I guess that's what BartC meant.

-- Alain.

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

#79540

Alain Ketterlin <alain@dpt-info.u-strasbg.fr>:

>>     j = (lambda: 3, lambda: j + 1)[j < 10]()
>
> This is just a way to delay evaluation *of the potential results*,
> i.e., instill a bit of lazyness.

That's one way to characterize a function, or code in general.

That point of view is apparent in PostScript, where control structures
are expressed "lazily" with lambdas:

    5 eq {
        gsave
        0.85 1 0.85 setrgbcolor
        fill
        grestore
    } if

The { ... } block is a piece of code pushed onto the stack.


Marko

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

#79564

Marko Rauhamaa wrote:

> "BartC" <bc@freeuk.com>:
> 
>>> Ah, but what would
>>>
>>> x = [f, g][cond]()
>>>
>>> produce?
>>
>> It will select f or g (which should refer to functions), and call one of
>> those depending on cond. That's not a problem.
>>
>> The problem is it will still evaluate both f and g,
> 
> That's not really the problem. The problem is in readability.


I don't get why that's considered hard to read. We write things like this
all the time:

item = somelist[index]
value = data[key]

Presumably people won't have a problem with:

values = [f(), g(), h()]
value = values[index]

(If they do, they're going to have a bad time with Python.) They probably
won't even mind if we skip the temporary variable:

value = [f(), g(), h()][index]

and if they're experienced with languages that treat functions as
first-class values, they'll be fine with factoring out the function call:

value = [f, g, h][index]()


So why is it hard to read when the index is a flag?

value = [f, g][cond]()


Of course one can write hard-to-read code using any idiom by sheer weight of
complexity or obfuscated naming:

value = [some_function(arg)[23]['key'] or 
         another_function.method((x + y)/(z-x**(y-4)))*
         some_list[get_index(a)].spam(eggs=False, tomato='yum'),
         something.do_this(p|q).get(alpha, beta) ^
         aardvark.bobble("string%s" % carrot.gamma(r&s)*
         (this & that).fetch(83, 36, when=when or "now")
         ][cond or flag or foo(42)-1 > 17 or bar(b) < thingy(c) or not d]


but re-writing that using ternary if operator won't help one iota. I don't
see why `[a, b][flag]` is inherently less readable than `b if flag else a`.



-- 
Steven

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

#79565

On Fri, Oct 24, 2014 at 7:38 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Of course one can write hard-to-read code using any idiom by sheer weight of
> complexity or obfuscated naming:
>
> value = [some_function(arg)[23]['key'] or
>          another_function.method((x + y)/(z-x**(y-4)))*
>          some_list[get_index(a)].spam(eggs=False, tomato='yum'),
>          something.do_this(p|q).get(alpha, beta) ^
>          aardvark.bobble("string%s" % carrot.gamma(r&s)*
>          (this & that).fetch(83, 36, when=when or "now")
>          ][cond or flag or foo(42)-1 > 17 or bar(b) < thingy(c) or not d]
>

I can see where your problem is. It is a cardinal error in readability
to have "(x + y)" followed by "z-x". No wonder it's hard to read.

ChrisA

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

#79566

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> So why is it hard to read when the index is a flag?
>
> value = [f, g][cond]()

So, subjectively, which syntax would you prefer:

    if j < 10:
        j += 1
    else:
        j = 3

or:

    j = j + 1 if j < 10 else 3

or:

    j = (lambda: 3, lambda: j + 1)[j < 10]()


Marko

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

#79568

Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
>> So why is it hard to read when the index is a flag?
>>
>> value = [f, g][cond]()
> 
> So, subjectively, which syntax would you prefer:

Depends on what else the code is doing. But my personal preference is a red
herring: you didn't say that you "liked" or "preferred" one version over
the other, you said that the problem with the [f, g][cond] idiom is
readability, implying that it is hard to read. I'm not asking for your
personal preference, I'm asking for justification for your suggestion that
it is hard to read.


>     if j < 10:
>         j += 1
>     else:
>         j = 3
> 
> or:
> 
>     j = j + 1 if j < 10 else 3
> 
> or:
> 
>     j = (lambda: 3, lambda: j + 1)[j < 10]()

Certainly not the third one. That's needlessly obfuscated for the sake of
premature optimization. This version is much better, and probably not only
simpler and easier to read but probably more efficient too:

    j = (3, j + 1)[j < 10]



-- 
Steven

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

#79600

On Fri, Oct 24, 2014 at 7:07 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> >>     if j < 10:
>>         j += 1
>>     else:
>>         j = 3
>>
>> or:
>>
>>     j = j + 1 if j < 10 else 3
>>
>> or:
>>
>>     j = (lambda: 3, lambda: j + 1)[j < 10]()
>
> Certainly not the third one. That's needlessly obfuscated for the sake of
> premature optimization. This version is much better, and probably not only
> simpler and easier to read but probably more efficient too:
>
>     j = (3, j + 1)[j < 10]

Yes, the lambda approach falls victim to function calls being slow.

$ python3 -m timeit -s "j = 5" "if j < 10: j+=1
> else: j=3"
10000000 loops, best of 3: 0.0513 usec per loop
$ python3 -m timeit -s "j = 5" "j = j + 1 if j < 10 else 3"
10000000 loops, best of 3: 0.0519 usec per loop
$ python3 -m timeit -s "j = 5" "j = (3, j+1)[j < 10]"
10000000 loops, best of 3: 0.0883 usec per loop
$ python3 -m timeit -s "j = 5" "j = (lambda: 3, lambda: j+1)[j < 10]()"
1000000 loops, best of 3: 0.312 usec per loop

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

#79604

Ian Kelly <ian.g.kelly@gmail.com>:

>>     j = (lambda: 3, lambda: j + 1)[j < 10]()

> Yes, the lambda approach falls victim to function calls being slow.

That's just a deficiency in the compiler. There's nothing there that
prevents the optimizer from translating the expression into the
equivalent if statement.

At any rate, the only issue at hand is the obviousness of the idiom. You
should generally choose the syntax that best expresses the logic of the
program.


Marko

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

#79590

On Fri, Oct 24, 2014 at 1:38 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I don't get why that's considered hard to read.

> So why is it hard to read when the index is a flag?
>
> value = [f, g][cond]()

It's clear to you, it's clear to me, but is it clear to everyone?  I
very much doubt it.

Also, you've gone to the trouble of def'ing two functions here - you
may as well do a function for the if/else.

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

#79613

On Fri, 24 Oct 2014 10:20:30 -0700, Dan Stromberg wrote:

> On Fri, Oct 24, 2014 at 1:38 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> I don't get why that's considered hard to read.
> 
>> So why is it hard to read when the index is a flag?
>>
>> value = [f, g][cond]()
> 
> It's clear to you, it's clear to me, but is it clear to everyone?  I
> very much doubt it.

I had to mentally step through this before it became apparent what it was 
doing,  can see places where it could be usefull (a switch replacement) 
but it is not instantly obvious

a = <value> if <condition> else <another Value>

is instantly obvious (at least to a native English speaker anyway)
> 
> Also, you've gone to the trouble of def'ing two functions here - you may
> as well do a function for the if/else.





-- 
"Humor is a drug which it's the fashion to abuse."
		-- William Gilbert

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

#79615

alister <alister.nospam.ware@ntlworld.com>:

> a = <value> if <condition> else <another Value>
>
> is instantly obvious (at least to a native English speaker anyway)

And you can go further down that road. For example, you could say things
like:

    die unless everything is OK


Marko

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

#79654

alister wrote:

> On Fri, 24 Oct 2014 10:20:30 -0700, Dan Stromberg wrote:
> 
>> On Fri, Oct 24, 2014 at 1:38 AM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> I don't get why that's considered hard to read.
>> 
>>> So why is it hard to read when the index is a flag?
>>>
>>> value = [f, g][cond]()
>> 
[Dan]
>> It's clear to you, it's clear to me, but is it clear to everyone?  I
>> very much doubt it.

Of course it won't be clear to *everyone* but it should be clear enough to
people who are familiar with standard Python idioms. A concrete example
should be more obvious than the fake example:

title = ('Mr', 'Ms')[person.sex == 'F']

which should be clear to anyone who understands indexing in Python and that
True == 1 and False == 0.

Although that's probably better written as a dict lookup:

title = {'M': 'Mr', 'F': 'Ms'}[person.sex]

which is then more easily extended to support intersex and
non-traditional[1] gender identities. Better still is to allow the
individual to choose their own title (Dr, Prof, Mrs, Miss, Mx, Sir, Dame,
etc.) rather than calculate it from their sex, but that's moving away from
the point I am making that this idiom isn't some weird and hackish
bizarrity. We use list indexing and key lookup all the time, this is just a
special case of the same. It's no more hackish than:

mapping = {True: "something which is factual",
           False: "something which people prefer to believe"}
value = mapping[flag]


[Alister]
> I had to mentally step through this before it became apparent what it was
> doing,  can see places where it could be usefull (a switch replacement)
> but it is not instantly obvious

Very little code is instantly obvious. Even when you know what the syntax
means, you still have to understand the semantics, and sometimes that's far
from obvious.


> a = <value> if <condition> else <another Value>
> 
> is instantly obvious (at least to a native English speaker anyway)

Ha! And yet people have, and continue to, complain *bitterly* about the
non-standard ordering of Python's ternary if, compared to C, standard
if...else syntax, and English.

"If the syntax is like C, then people will use it, or else they will
complain that the syntax is incomprehensible."

Personally, I don't accept or agree with such complaints. Python's ternary
if follows the same syntax as this English variant:

"People will use it if the syntax is like C, or else they will complain that
the syntax is incomprehensible."

Still, English-like though it is, Python's ternary if does violate the
expectations of those who expect the condition to come first, as the
standard if...else block does.


[Dan]
>> Also, you've gone to the trouble of def'ing two functions here - you may
>> as well do a function for the if/else.

Not every one-liner expression needs to go into a function.




[1] For Western Christian definitions of traditional. Other cultures have
traditionally recognised more than just a binary state of gender and
sexuality, e.g. https://en.wikipedia.org/wiki/Hijra_%28South_Asia%29

-- 
Steven

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

#79655

On Sat, Oct 25, 2014 at 4:03 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Ha! And yet people have, and continue to, complain *bitterly* about the
> non-standard ordering of Python's ternary if, compared to C, standard
> if...else syntax, and English.
>
> "If the syntax is like C, then people will use it, or else they will
> complain that the syntax is incomprehensible."
>
> Personally, I don't accept or agree with such complaints. Python's ternary
> if follows the same syntax as this English variant:
>
> "People will use it if the syntax is like C, or else they will complain that
> the syntax is incomprehensible."

Partly, I think this is a difference between programming and pure
mathematics. In algebra, there's operator precedence, but no order of
evaluation; in programming, there's both:

https://docs.python.org/3/reference/expressions.html#evaluation-order

In English, there's not really a concept of order of evaluation
either. "People will use it" doesn't need to be evaluated separately
from "if the syntax is like C". But in Python, the if/else operator
mucks up the general principle that an expression will be evaluated
left-to-right, because it's evaluated middle-to-outer for that one
operator. Messing with internal expectations, even if it's following
some external logic like English grammar, will confuse people.

ChrisA

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

#79664

On 10/25/14 1:03 AM, Steven D'Aprano wrote:
> alister wrote:
>
>> >On Fri, 24 Oct 2014 10:20:30 -0700, Dan Stromberg wrote:
>> >
>>> >>On Fri, Oct 24, 2014 at 1:38 AM, Steven D'Aprano
>>> >><steve+comp.lang.python@pearwood.info>  wrote:
>>>> >>>I don't get why that's considered hard to read.
>>> >>
>>>> >>>So why is it hard to read when the index is a flag?
>>>> >>>
>>>> >>>value = [f, g][cond]()
>>> >>
> [Dan]
>>> >>It's clear to you, it's clear to me, but is it clear to everyone?  I
>>> >>very much doubt it.
> Of course it won't be clear to*everyone*  but it should be clear enough to
> people who are familiar with standard Python idioms. A concrete example
> should be more obvious than the fake example:
>
> title = ('Mr', 'Ms')[person.sex == 'F']
>
> which should be clear to anyone who understands indexing in Python and that
> True == 1 and False == 0.

You mention "standard Python idioms."  I think this style of 
conditional-via-indexing is becoming quite uncommon, and is no longer 
one of the standard Python idioms.  This is now in the category of 
"outdated hack."

Yes, its meaning is well-defined by the language.  But no, its meaning 
is not immediately apparent to most of today's Python programmers.

Of course, opinions obviously differ.

-- 
Ned Batchelder, http://nedbatchelder.com

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

#79669

On Sat, Oct 25, 2014 at 5:58 AM, Ned Batchelder <ned@nedbatchelder.com> wrote:
> You mention "standard Python idioms."  I think this style of
> conditional-via-indexing is becoming quite uncommon, and is no longer one of
> the standard Python idioms.  This is now in the category of "outdated hack."

I think that's probably true. And even in code written for versions of
Python than predate the ternary, I think I've seen the idiom "(cond
and [if_true] or [if_false])[0]" more often than the one being
discussed -- perhaps because it more closely resembles the format of
the C ternary

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web