Too much code - slicing
usenet-nospam at seebs.net
Tue Sep 21 02:41:31 CEST 2010
On 2010-09-21, Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> wrote:
> On Mon, 20 Sep 2010 19:28:49 +0200, Antoon Pardon wrote:
>> Not necessarily. Some of us have the impression that Guido deliberatly
>> chose an ugly format for the ternary operator.
> If he did, then he must have changed his mind, because there is nothing
> ugly about the ternary operator we ended up with.
Empirically, looking at the commentary on the PEP, there is something
about it which a large number of participants found awkward or dislikeable.
I'm not sure I'd say "ugly", but I would say that the net result is
that it is likely more error-prone than an arrangement which put the
conditions and clauses in the order they're in for other conditionals.
> It astounds me how the Python community changed it's collective mind from
> admiration of the elegance and simplicity of the expression when it was a
> buggy hack, to despising it when it became a bug-free language feature.
> Go figure.
Well, if I had to point at an explanation, I'd guess it's the inversion.
That, and things of the general form "x or y" are found in several other
scripting languages, so it's a more familiar idiom.
But I suspect some of it is just that, well, a number of people as of the
original PEP discussion on the conditional operator disliked the "new"
proposal of "x if y else z", and if they still dislike it, they'll find
the conditional operator unpleasant even if it's bug-free.
This may come as a total shock, but in modern scripting languages, people
are often substantially concerned with style, not just with whether or not
something works. :) I would probably tend to avoid the Python conditional
as it currently exists because I know that a fair number of people will
find it mildly confusing.
Not that they won't be able to parse it, but... It's like phrasing tests
negatively. It adds one chunk to the cognitive load of reading something.
It increases the likelihood of the user making mistakes -- and no amount
of polish and debugging of the engine can prevent users from making mistakes.
The implementation in the language engine may be bug-free, but I'd be less
optimistic about code which used the construct.
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam at seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
More information about the Python-list