Home Original page

comprehensions was Re: Switch statements again

Beni Cherniavsky cben at techunix.technion.ac.il
Mon Jan 20 12:14:18 EST 2003 
On 2003-01-19, John Roth wrote:

>
> "Beni Cherniavsky" <cben at techunix.technion.ac.il> wrote in message
> news:Pine.GSO.4.44_heb2.09.0301191441590.20859-100000 at techunix.technion.
> ac.il...
> > On 2003-01-17, Tim Peters wrote:
> >
> >
> > > but then I never expected anyone to do
> > >
> > > (f() and [g()] or [h()])[0]
> > >
> > > in real life either <0.5 wink>.
> > >
> > That should be written ``f() and g() else h()`` <wink>.
>
> Actually not. Tim, as usual, has it right. The way
> you wrote it fails if g() evaluates to a false value.
> That's been the standard problem with this construct.
>
The way I wrote it is a syntax error (notice the ``else``).  What I meant
is to suggest the and..else syntax for the properly working ternary
operator, if it's ever added.  Tim's ``<wink>``-s, as usual, are more
clearly visible than mine :-)

> The way Tim has it, [g()] cannot evaluate to a false value. It's always
> a 1 element list which by definition is true.
>
To make it even uglier, I once wrote (on the command line, I don't hold
such horrors in real code :-) this with singleton tuples to make it
faster::

    (f() and (g(),) or (h(),))[0]

Now it's completely unreadable :-).  I frequenlty find myself using lists
instead of tuples only because they are more readable...

("-ly",)["y'rs"]
    Beni Cherniavsky <cben at tx.technion.ac.il>

There is an Excel spreadsheet here.  Do you want to open it? y
There was a grid bug in the spreadsheet.  The grid bug bites.
More information about the Python-list mailing list