PEP 308: A PEP Writer's Experience - PRO
Andrew Henshaw
andrew.henshaw at gtri.gatech.edu
Sun Feb 9 23:31:38 EST 2003
Andrew Koenig wrote:
> Samuele> As you might know the "cutest" (my take) general solution to
> Samuele> the problem in current Python (performance aside), has been
> Samuele> posted by Gerald S. Williams to python-dev:
>
> Samuele> ife = lambda box: box[0]
>
> Samuele> z = ife(cond and [x] or [y])
>
> Samuele> if Python had had a ternary cond op, I would never have seen
> Samuele> that <sniff>.
>
> You're right -- that's about the nicest workaround I've seen.
>
> But I think I can improve it a tiny bit:
>
> ife = list.pop
>
> Shorter and faster, yes?
>
That's nice.
This is getting closer to the discussion that I'd like to see - that is,
making this "ternary operator" into a function.
I understand about the lazy evaluation problem, and I wonder if that
couldn't be solved in general, and we'd get a bonus out of this whole
discussion. In other words, if someone could propose a workable lazy
evaluation solution, then we'd have the benefits of that technology, plus
we'd could have a cleaner (in my opinion) solution to the problem at hand.
Why cleaner? Personally, I find the use of multiple keywords and intermixed
expressions on a single line, with no punctuation, difficult to parse
(particularly, when chained). To me
expr1 keyword1 cond keyword2 expr2
is more difficult to read than
function(cond, expr1, expr2)
The commas also provide the benefit of naturally supporting multiples lines,
such as:
function(cond,
really_long_expression,
really_really_long_expression)
In addition, the required parentheses make abuse of the construct less
probable. For example,
expr1 keyword1 cond1 keyword2 expr2 keyword1 cond2 keyword2 expr3 (I think)
versus
function(cond1, expr1, function(cond2, expr2, expr3))
seems to be a win for the function style. Perhaps, I'm making things worse
by abstracting the terms, too much.
expr1 if cond1 else expr2 if cond2 else expr3
versus
iff(cond1, expr1, iff(cond2, expr2, expr3))
Back to the top of this post - a workaround has been suggested that
essentially achieves lazy evaluation. Clearly one of the problems here is
that the caller has to coerce that capability, instead of the called
function providing it.
Would it not be reasonably possible (even Pythonic), for there to be an
argument qualifier that denoted lazy evaluation in the function definition,
similar to the * and ** qualifiers now used? Or is lazy evaluation itself
too difficult (or dangerous) to implement in Python?
If it were possible, then we might have (arbitrarily choosing a qualifier)
def iff(cond, %expr1, %expr2):
if cond:
return expr1
else:
return expr2
Plus that whole lazy-evaluation-infinite-data-structures capability comes
along as well (assuming someone very clever can develop it).
I'm certainly opposed to adding line-noise artifacts to Python, but this
would be very rarely used, it would be restricted to the def statement, and
it would be documented along with the * and ** qualifiers.
Regards,
Andy
More information about the Python-list
mailing list