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