Alternative suggestion for conditional expressions (see PEP 308)

[Colin J. Williams]

I was inclined to support PEP 308, but now wonder whether it's really 
needed.

sColorName = ("Black","White")[Color == COLOR_WHITE]

Could be:

sColorName = Color == COLOR_WHITE and "Black" or "White"

which takes avantantage of the short circuit evaluation

sColorName= color == colorwhite and "white" or garbage

This gives the correct result when only the first case needs to be 
evalutated.

Colin W.

neblackcat wrote:
> Would anyone like to comment on the following idea?
> 
> I was just going to offer it as a new PEP until it was suggested that
> I post it here for comment & consideration against PEP 308.
> 
> I'm far from being a "language internist" (on Python or anything else)
> so go easy on me if this is stupid - it just seemed quite elegant to
> me as a relative newbie in town :-)
> 
> I also havent got a clue whether this would be easy or even possible
> to implement even if it was deemed a reasonable idea.
> 
> -----------------------------------------------------------------------
> 
> Abstract
> 
>     Implement C-like conditional expressions, but in a more
>     flexible and "Python-like" way.
>    
> Motivation
> 
>     The lack of conditional expressions combined with the lack
>     of a 'switch' statement in Python tends to result in lots
>     of 'if'/'elif' lines which often arent needed and which make 
>     code more verbose and sometimes (where there are a lot of 
>     them) harder to follow and more prone to mistakes than it 
>     needs to be.  
> 
>     This PEP attempts to address that by proposing a
>     'Pythonesque' conditional expressions language feature
>     which fits well with existing language features
>     and the way that conditional expressions are often
>     simulated in current Python code by using temporary
>     tuples, lists or dictionaries.
> 
> 
> Rationale
> 
>     It is currently possible to simulate conditional
>     expressions in Python using constructs with
>     temporary tuples/lists, such as:
> 
>     sColorName = ("Black","White")[Color == COLOR_WHITE]
> 
>     This works, but has two disadvantages:
> 
>     i)  it involves packing and unpacking of a 'temporary'
>         tuple, eg. ("Black","White") in the above, which
>         has performance implications
> 
>     ii) this in turn means that *all* of the possible 
>         final values have to be valid (not just the one
>         which will be actually selected), which is often
>         not the case in a more real-world example, eg:
> 
>         r = (DEFAULT_RESULT, Database.Results[index])
>               [IsValid(index)]
> 
>         In the above, 'Database.Results[index]' isn't
>         defined to be valid if the 'index' value isn't,
>         which means that this technique cant be used. 
> 
> Specification
> 
>     I therefore suggest a variation on the above
>     syntax such as:
> 
>     sColorName = ?("Black","White")[Color == COLOR_WHITE]
> 
>     where the '?' identifies the immediately following
>     tuple as a "conditional tuple" in which the tuple is 
>     not actually fully evaluated/stored.  Instead,
>     only the element specified  by the immediately following
>     index expression is evaluated and must be valid.
> 
>     This syntax could also apply to other sequence types,
>     for example dictionaries:
> 
>     sColorName = ?{COLOR_RED:"Red", 
>                    COLOR_BLUE:"Blue",
>                    COLOR_GREEN:"Green"}[ColorValue]
> 
>     Again, the conditional sequence is not fully evaluated/stored,
>     so it doesnt matter if it is large and/or has members which
>     arent evaluated given an index value which doesnt actually
>     select them.
> 
>     Obviously, the above are just simple examples.