PEP 308: A PEP Writer's Experience - CON

Andrew Koenig ark at research.att.com
Sat Feb 8 12:31:46 EST 2003


I agree completely what everything Michael said in this note,
so I won't quote it all.  I do, however, want to augment a few
minor points:

Michael>If you meant any of these

Michael>        x = (condition and [a] or [b])[0]

Michael>        x = (condition and (lambda:a) or (lambda:b))()

Michael>        def ternary(condition, f1, f2):
Michael>            if condition:
Michael>                return f1()
Michael>            else:
Michael>                return f2()
Michael>        x = ternary(condition, lambda a, lambda b)

Michael> then you should be ashamed of yourself - try explaining any
Michael> one of them to a beginner. And anyway, Python is known for
Michael> its readability and clarity... tricky-to-understand workarounds
Michael> should NOT be our standard approach to anything.

And anyway, the last example is wrong: it should say

                x = ternary(condition, lambda: a, lambda: b)

Michael>      [3d] if condition: val1 else: val2
Michael>       - overuse of :
Michael>       - ambiguity with if statement could make it hard to read
Michael>       - ambiguity with if statement makes it impossible for
Michael>           Python's parser

Does it really?  I would think it sufficient to distinguish an
"if" as the first token of a statement from all others.


Michael> [4] Quit changing Python -- I liked it as a small language

Michael> If you compare the introduction of a ternary operator to
Michael> recent changes, it's a much smaller change than the
Michael> introduction of list comprehensions, or introducing generators.
Michael> It won't break any code like fixing division did. It is not
Michael> a deep and powerful change like nested scopes or new-style
Michael> classes. About the only change it's comparable to is the
Michael> introduction of boolean. Really... there's no new conceptual
Michael> overhead (not a deep or confusing idea like metaclasses) --
Michael> I understand why some might like to slow the changes to
Michael> Python, but this is not the right change to object to.

Perhaps this is why there's so much debate :-)  Seriously, it
often seems that the smallest changes generate the most controversy.

-- 
Andrew Koenig, ark at research.att.com, http://www.research.att.com/info/ark




More information about the Python-list mailing list