Too much code - slicing

[rantingrick]

To my eyes, the feature of syntax highlighting that alone makes it
worthwhile, its killer feature, is that I can set comments and docstrings
to grey. When I'm scanning code, being able to slide my eyes over greyed-
out comments and docstrings and ignore them with essentially zero effort
is a huge help. That's the thing I most miss, more than anything else,
when using a dumb editor.

Well dumb editors use syntax highlighting also... specifically the
ones that default to bright (attention grabbing!) colors for comments
and/or docstrings... like the color RED! Gawd i hate that! Never
should a comment be a bright color, and RED is the worst choice of
all! Grey for comments, orange for keywords, purple for builtins, and
green for strings is pure bliss. Save red for scary things like global
variables and such. That way you know where the hemorrhaging is coming
from!

 

[Antoon Pardon]

If he did, then he must have changed his mind, because there is nothing
ugly about the ternary operator we ended up with.

That is a question of taste and the poll and discussion earlier made it clear
that this was not the preferred way to have a ternary operator. This form
only ranked fourth (or maybe third), with the first three all wanting ar
structure with the elelement is this order: condition, true case, false case

Guido has alwasys been
against a ternary operator but the requests kept coming. So eventually
he introduced one. But the impression is that he chose an ugly format in
the hope of discouraging people to use it.

That's sheer and unadulterated nonsense. The fact is that Guido changed
his mind about ternary if after discovering that the work-around

true-clause and condition or false-clause

is buggy -- it gives the wrong answer if true-clause happens to be a
false value like [], 0 or None. If I recall correctly, the bug bit Guido
himself.

Nonsense. That the work around was buggy was known years before the
ternary operator was finally introduced. The introduction of list
comprehension made a ternary operator that more usefull but every
time it came up the supporters of Guido, told us we just had to
define a function if we wanted the items to depend on a condition.

And we knew about the problem, that is why we discussed bug-free
alternatives like:

condition and [true-expr] or [false-expr][0]

or

condition and (lambda: true-expr) or (lambda: false-expr)()

The and-or hack, which was *very* common in Python code for many years
and many versions, follows the same pattern as ternary if:

true-clause if condition else false-clause

No it doesn't. the and-or-hack follows the same pattern as the if
statement.

condition, true clause, else clause

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.

It seems that what changed is your memory and not the collective mind of
the python community.

We had an if statement and a (buggy) hack that followed the same pattern.
An earlier discussion and poll had revealed that people n general preferredr
to keep that pattern in a conditional expression. So why should you be
surprised when people express that they would have preferred a conditional
expression with a different pattern than we have now.

 

[Andreas Waldenburger]

I also like this construct that works, I think, since 2.6:

code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]

I wonder when this construct will finally start to look good.

I don't know if it'll ever look good, per se, but it looks better when
it's used in rule-exception sort of case:

something = rule if condition else exception

Spot on. I (more or less) like it when used that way, too. But it seems
to invite crackers like the example above, and that irks me.

/W

 

[Steven D'Aprano]

I guess you have worked hard to forget the and-or hack. It was actually:

condition and true-clause or false-clause

so its not quite the same pattern.

So I did. Oops.

Thanks for the correction.

 

[Steven D'Aprano]

That is a question of taste

Yes, it certainly is. Describing it as "an ugly format" is also a matter
of taste -- taste which in my opinion simply isn't justified by anything
other than familiarity.

and the poll and discussion earlier made it
clear that this was not the preferred way to have a ternary operator.

"Not preferred" != "ugly"

This form only ranked fourth (or maybe third), with the first three all
wanting ar structure with the elelement is this order: condition, true
case, false case

Guido has alwasys been
against a ternary operator but the requests kept coming. So
eventually he introduced one. But the impression is that he chose an
ugly format in the hope of discouraging people to use it.

That's sheer and unadulterated nonsense. The fact is that Guido changed
his mind about ternary if after discovering that the work-around

true-clause and condition or false-clause

is buggy -- it gives the wrong answer if true-clause happens to be a
false value like [], 0 or None. If I recall correctly, the bug bit
Guido himself.

Nonsense. That the work around was buggy was known years before the
ternary operator was finally introduced.

But people kept forgetting it, and it bit the right person one time too
many.

The introduction of list
comprehension made a ternary operator that more usefull but every time
it came up the supporters of Guido, told us we just had to define a
function if we wanted the items to depend on a condition.

A function can't do the job, because it isn't lazy:

def ifte(condition, x, y):
if condition: return x
else: return y

n = 0
ifte(n != 0, 100/n, -1)


will fail. This was perhaps *the* killer argument for a ternary-if
operator.


[...]

It seems that what changed is your memory and not the collective mind of
the python community.

Fair call.

 

[Steven D'Aprano]

I also like this construct that works, I think, since 2.6:

code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]

I wonder when this construct will finally start to look good.

I don't know if it'll ever look good, per se, but it looks better when
it's used in rule-exception sort of case:

something = rule if condition else exception

Spot on. I (more or less) like it when used that way, too. But it seems
to invite crackers like the example above, and that irks me.

I don't see that one of these is more of a cracker than the other:


code = if side == 'l' then dir[int(num):] else dir[:-1*int(num)]
code = side == 'l' if dir[int(num):] else dir[:-1*int(num)]
code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]


If you ask me, the *least* hard to read is the last.

Unary and binary operators are natural in a language which is parsed in a
single dimension (left-to-right in the case of English). There is no
entirely natural way to parse a ternary operator, because you need to fit
three operands into two slots. That's why mathematicians often use two
dimensions when they need a ternary operator, like sum:

∞
∑ expr
i=0

 

[John Bokma]

For completeness sake:

code = side == 'l' ? dir[int(num):] : dir[:-1*int(num)]

code = if side == 'l' then dir[int(num):] else dir[:-1*int(num)]
code = side == 'l' if dir[int(num):] else dir[:-1*int(num)]
code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]


If you ask me, the *least* hard to read is the last.

For me the (newly added) first one, because it has (for me) less noise.

But I can certainly live with the last one. Or all for that matter. Or
maybe: since the results are already somewhat complex (or noisy) I
probably would use a "normal" if else.

What surprises me is that this is still discussed. It's like argueing
about significant whitespace.

 

[Seebs]

Yes, it certainly is. Describing it as "an ugly format" is also a matter
of taste -- taste which in my opinion simply isn't justified by anything
other than familiarity.

It may not be convincing to other people, but the logical inversion strikes
me as a taste issue which goes beyond mere familiarity. It is not
unreasonable to continue to dislike something which breaks a general
principle even after long familiarity.

So I think there is a real issue. There are arguments going the other way,
and while they don't fit my sense of aesthetics, I guess they aren't
strictly required to.

But I do think it's unfair to dismiss it as purely a matter of baby duck
syndrome. Consistency in ordering of corresponding idioms seems a reasonable
goal.

-s

 

[Steven D'Aprano]

But I do think it's unfair to dismiss it as purely a matter of baby duck
syndrome. Consistency in ordering of corresponding idioms seems a
reasonable goal.

I don't see anyone bitching about:

for x in seq:
if x:
f(x)

vs

[f(x) for x in seq if x]

 

[Seebs]

I don't see anyone bitching about:

for x in seq:
if x:
f(x)

vs

[f(x) for x in seq if x]

In my case, that's because I only ran into that syntax about an hour and
a half ago. I have the same basic objection to it. If it were:

[for x in seq: if x: f(x)]

I'd find it substantially easier to understand.

I don't generally like constructs where important structural information
comes late in the construct. In the trivial case, I don't suppose it makes
a huge difference, but think about the case where seq starts with a (
and x ends with one:

[f(x) for x in (1, 2, 3) if foo(x)]

As the expressions get complicated, that gets harder to see. IMHO.

I dunno. I like the "next if /^$/" idiom, but anything more complicated
for either the condition or the thing conditionalized and I tend to
prefer to jump back to an explicit if statement.

-s

 

[John Bokma]

I dunno. I like the "next if /^$/" idiom,

I don't (as a Perl programmer), I prefer:

$line =~ /^$/ and next;

Or:

$line ne '' or next;

which I read as: line must not be empty

 

[Seebs]

I don't (as a Perl programmer), I prefer:

Huh, those are actually nicer. I didn't know that was possible; it
wouldn't have occurred to me to try to put "next" (which I think
of as a statement) into an expression.

Basically, I can live with a postfix "if" as long as everything
involved is trivial. Past that... I'd rather see the condition
up front.

-s

 

[Andreas Waldenburger]

On 2010-09-23, Steven D'Aprano <[email protected]>
wrote:
[snip]

I don't see anyone bitching about:

for x in seq:
if x:
f(x)

vs

[f(x) for x in seq if x]

In my case, that's because I only ran into that syntax about an hour
and a half ago. I have the same basic objection to it. If it were:

[for x in seq: if x: f(x)]

I'd find it substantially easier to understand.

I don't generally like constructs where important structural
information comes late in the construct. [snip]

I think that is precisely the reason that the elements of the list come
*first* in the list comprehension expression. The foremost idea of list
comprehensions is "build a list", while the idea of a for-loop is
"iterate over something".

/W

 

[Andreas Waldenburger]

On Sep 17, 1:01 pm, Andreas Waldenburger <[email protected]>
wrote:
I also like this construct that works, I think, since 2.6:

code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]

I wonder when this construct will finally start to look good.

I don't know if it'll ever look good, per se, but it looks better
when it's used in rule-exception sort of case:

something = rule if condition else exception

Spot on. I (more or less) like it when used that way, too. But it
seems to invite crackers like the example above, and that irks me.

I don't see that one of these is more of a cracker than the other:


code = if side == 'l' then dir[int(num):] else dir[:-1*int(num)]
code = side == 'l' if dir[int(num):] else dir[:-1*int(num)]
code = dir[int(num):] if side == 'l' else dir[:-1*int(num)]


If you ask me, the *least* hard to read is the last.

I agree again. I wasn't really talking about the specific order of the
ternary operator but rather about the whole idea. It invites messiness.

/W

 

[Andreas Waldenburger]

What surprises me is that this is still discussed. It's like argueing
about significant whitespace.

Which is evil!

/W

 

[Seebs]

I don't generally like constructs where important structural
information comes late in the construct. [snip]

I think that is precisely the reason that the elements of the list come
*first* in the list comprehension expression. The foremost idea of list
comprehensions is "build a list", while the idea of a for-loop is
"iterate over something".

Interesting! I tend to think of "building a list" as more like a for loop
than like a data item with a qualifier. If the first word inside the
[] were "for", that would tell me that the list was going to have some kind
of looping or generating going on, while if it's an expression, especially
a complicated expression, I don't know that right away.

But I can see it making sense either way for the loop, just because of
the similarity to mathematical notation.

-s

 

[Steven D'Aprano]

Which is evil!

Iagreethatsignioficantwhitespaceisevil.Pythonshouldbelikeearlyver
sionsofFortran,whichhadnosignificantwhitespace.Muchbetter,inmyopi
nion.


*wink*

 

[Antoon Pardon]

Yes, it certainly is. Describing it as "an ugly format" is also a matter
of taste -- taste which in my opinion simply isn't justified by anything
other than familiarity.

There is the facts that it broke familiarity with a common pattern.

This form only ranked fourth (or maybe third), with the first three all
wanting ar structure with the elelement is this order: condition, true
case, false case

Guido has alwasys been
against a ternary operator but the requests kept coming. So
eventually he introduced one. But the impression is that he chose an
ugly format in the hope of discouraging people to use it.

That's sheer and unadulterated nonsense. The fact is that Guido changed
his mind about ternary if after discovering that the work-around

true-clause and condition or false-clause

is buggy -- it gives the wrong answer if true-clause happens to be a
false value like [], 0 or None. If I recall correctly, the bug bit
Guido himself.

Nonsense. That the work around was buggy was known years before the
ternary operator was finally introduced.

But people kept forgetting it, and it bit the right person one time too
many.

So? That it took years between the knowledge that the work-around failed
and a ternary operator finally appearing is still a fact. Which casts doubts
that is was this knowledge that made him change his mind.

A function can't do the job, because it isn't lazy:

def ifte(condition, x, y):
if condition: return x
else: return y

n = 0
ifte(n != 0, 100/n, -1)

will fail. This was perhaps *the* killer argument for a ternary-if
operator.

You really don't seem to remember what happened then.

Someone would come with a problem that we can now solve as follows.

ls = [ el / 2 if el % 2 == 0 else 3 * el + 1 for el in ls ]

and the respons would be that we just needed to write is as follows:

def f(el):
if el % 2 == 0:
return el / 2
else:
return 3 * el + 1

ls = [ f(el) for el in ls ]