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

Bjorn Pettersen BPettersen at NAREX.com
Mon Feb 10 13:50:11 EST 2003


> From: Andrew Koenig [mailto:ark at research.att.com] 
[...]
> Some people would write something like this:
> 
>         strs = []
>         for i in ints:
>             if i < 0:
>                 strs.append("?")
>             else:
>                 strs.append(str(i))
> 
> but others (including me) would like to be able to write this:
> 
>         strs = [("?" if i < 0 else str(i)) for i in ints]
> 
> I find this example easier to understand than the previous one.

As do I... however, I feel obliged to bring up the programming language
TOM (http://www.gerbil.org/tom/). It started out as Objective-C, and
then through an iterative process added distinct, small, self-contained
changes that by themselves were very reasonable. Now, however, many TOM
programs that utilize the symbiosis of the new features can't be
understood by Objective-C programmers. This is perhaps not a big problem
when creating a new language, but I think it would be a disaster for
Python. We should avoid the temptation to add syntax, especially for
infrequently used or esoteric constructs. That doesn't mean we shouldn't
consider adding constructs that have proven themselves in other
languages. For everything else, the best we can probably do is rely on
Guido's uncanny feel for what is Pythonic -- unlike most of us (me
included), he's got a proven track record <wink>

In the above, I think perhaps the list comp is causing too much to be
done on one line, I would probably code:

 strs = []
 for i in ints:
     strs.append( ("?" if i<0 else str(i)) )

i.e. I don't see the conditional expression as a problem, while I do
think that some overzelous uses of list comps can be a problem (for
simple uses they're a clear win though :-)

I'm still

 +1 on PEP 308 as submitted
 -1 on other enhancements to the proposal that have been posted[1]
 -2 on extending the "if"-expr with elif[2]

-- bjorn

[1] For me, it would be nice to get conditional expressions into the
language. Like it or not, Guido's proposal is probably the best chance
at accomplishing that. It is not a bad proposal, and all the
improvements I've seen suggested have been mostly cosmetic, and
bickering about these kinds of details seem like a sure way to lose
Guido's interest. For an other proposal to have any chance, I would
expect it to be obviously (far) superior to the PEP. (sorry if this
comes through as a little harsh...)
[2] Conditional expressions are all about concise expression of a simple
choice. If it isn't a simple choice, I can see no purpose in making it
concise, except for obfuscating the language.





More information about the Python-list mailing list