Home Original page

For review: PEP 308 - If-then-else expression

Chris Liechti cliechti at gmx.net
Sun Feb 9 15:00:04 EST 2003 
Alex Martelli <aleax at aleax.it> wrote in 
news:WMv1a.156906$0v.4393693 at news1.tin.it:

> Piet van Oostrum wrote:
>    ...
>> What about:
>>         condition -> (true part, false part)
>> The (,) is not a tuple here but it belongs to the -> and the -> says to
>> select one of the expressions based on the condition and evaluate that;
>> kind of lazy indexing.
>> 
>> We could then also have one for ints rather than bools:
>> 
>>         i -> [ v_0, v_1, v_2, ... ]
>> which would pick v_i and evaluate that.
> 
> This is the first syntax I've seen proposed for this that I _like_.
> 
> I particularly like the generalization to an int on the LHS of the
> new proposed -> operator.  However, I am slightly troubled by the
> subtly different syntax for the two-alternatives vs N-alternatives
> usages.  Whatever kind of parentheses are used, couldn't the
> number of alternatives listed inside the parentheses be the ones
> that control whether the LHS is taken as int or condition?  Or
> would that be unpythonic?  I don't feel very certain about this.

or we'd reverse the order in the RHS

cond -> (true, false)
int -> (4, 3, 2, 1)

i think that it would NOT be good to change the order depending on two or 
more elements, especialy as True==1 and False==0

using it in reverse order also makes it more distinct to
(false, true)[cond]
which will be brought up by anyone that has not understand that the -> 
solution is 'short curcuiting' or lazy evaluated (in this case the later is 
the better term?) 

as for parantheses, i'd probably allow both as in the result unpacking 
already suported (as in [a,b] = 1,2  <=> (a,b) = 1,2 <=> a,b = 1,2), 
IndexError for out of bounds indices and i would allow a tuple or a list as 
variable in the RHS ( y = cond -> my_list ).

i like that proposal.

chris

-- 
Chris <cliechti at gmx.net>
More information about the Python-list mailing list