For review: PEP 308 - If-then-else expression
Michael Hudson
mwh at python.net
Mon Feb 10 05:10:50 EST 2003
Paul Rubin <phr-n2003b at NOSPAMnightsong.com> writes:
> Michael Hudson <mwh at python.net> writes:
> > An example:
> >
> > def get_arg(self, default=1):
> > """Return any prefix argument that the user has supplied,
> > returning `default' if there is None. `default' defaults
> > (groan) to 1."""
> > if self.arg is None:
> > return default
> > else:
> > return self.arg
> >
> > could become
> >
> > def get_arg(self, default=1):
> > """Return any prefix argument that the user has supplied,
> > returning `default' if there is None. `default' defaults
> > (groan) to 1."""
> > return default if self.arg is None else self.arg
> >
> > Is that an improvement? *I* certainly don't think so. The original
> > has all these wonderful visual cues about what's going on (colons at
> > end of lines and indentation being the key two). The second just has
> > a stream of name-like tokens. It looks better when syntax hilighted,
> > but only slightly.
>
> Think of how you actually call get_arg:
>
> a = x.get_arg()
>
> In order to read that line you have to actually go check the
> definition of get_arg.
No, you have to know what get_arg() does.
> The conditional expression (maybe) simplifies your code, not by
> shortening the get_arg function, but by eliminating it. You'd
> instead say
>
> a = self.arg if (self.arg is not None) else 1
>
> or whatever.
I posted out of context so you weren't to know this, but: no!
In this case get_arg() is a (one) conceptual feature; it is also
(only, I think) called from outside the class that defines it.
> Maybe that syntax is clumsy but it still seems preferable to having
> to scroll to some method definition several screens away in order to
> find a 4-line function definition that needs 3 lines of
> documentation to explain what it's doing.
In this case, I really don't think so.
Cheers,
M.
--
> Touche! But this confirms you are composed of logic gates.
Crud, I thought those were neurons in there.
-- Thomas F. Burdick, Kenny Tilton, comp.lang.lisp
More information about the Python-list
mailing list