if the else short form

[Andreas Waldenburger]

On Fri, 1 Oct 2010 00:42:34 -0700 (PDT) "bruno.desthuilliers at gmail.com"
<bruno.desthuilliers at gmail.com> wrote:

> On 30 sep, 19:22, Andreas Waldenburger <use... at geekmail.INVALID>
> wrote:
> > On Thu, 30 Sep 2010 03:42:29 -0700 (PDT)
> >
> > "bruno.desthuilli... at gmail.com" <bruno.desthuilli... at gmail.com>
> > wrote:
> > > On 29 sep, 19:20, Seebs <usenet-nos... at seebs.net> wrote:
> > > > On 2010-09-29, Tracubik <affdfsdfds... at b.com> wrote:
> > > > > button = gtk.Button(("False,", "True,")[fill==True])
> >
> > > > Oh, what a nasty idiom.
> >
> > > Well, it's not very different from dict-based dispatch , which is
> > > the core of OO polymorphic dispatch in quite a few dynamic OOPLs.
> >
> > > Anyway, it's a common Python idiom and one that's not specially
> > > hard to grasp so I don't see any legibility problem here.
> >
> > But it does violate the "explicit is better than implicit" tenet,
> > don't you think?
> 
> Why so ? The doc clearly states that booleans are integers with True
> == 1 and False == 0, so there's nothing implicit here.
> 
The Perl docs state a lot of things about Perl also; that doesn't make
Perl any more explicit as a language.

I understand the term "explicit" to mean (broadly) "code that
documents itself as clearly as possible". To me the
["A","B"][bool(switch)] idiom doesn't readily translate into an English
phrase, even though I understand it. As such, it takes me longer to
grasp it's purpose than an ".. if .. else ..." expression. Therefore, I
consider this functionality implicit, rather than explicit.

This may be a too liberal a reading of said tenet, so ... yeah.

/W

-- 
INVALID? DE!