Too much code - slicing

[AK]

On 09/19/2010 02:21 PM, Seebs wrote:
> On 2010-09-19, AK<andrei.avk at gmail.com>  wrote:
>> On 09/19/2010 03:31 AM, Seebs wrote:
>>> Just like:
>>> 	if condition:
>>> 	    foo
>>> 	else:
>>> 	    bar
>
>>> The condition is the primary, the clauses are secondary to it.
>
>> To me, the problem with C ternary is, why is true condition first and
>> false second? It could just as well be the other way around.
>
> Again, look at the long-form "if/else" above; it's always "if a then b
> otherwise c".

Because that's what 'if' and 'else' mean. I have no problem with '?'
separating condition from possible outcomes.. The most natural reading
of that construct is that depending on condition, there are two possible
outcomes, separated by a ':' and you have to remember that first outcome
corresponds to true condition. x = y if a else z is much more pythonic
because 'else' is explicitly saying what happens on false condition.
Explicit is better than implicit.

>
>> That's absolutely not how I read code. For example, if you have a line
>> like:
>
>>    x = x + 1 ASF!@#$!@$ASFASF!@#$!@$#ADFASDF!@#
>
>> Do you read it as "ok, assignment.. x is x + 1.. whoa, what the hell is
>> this?".
>
> Not for something that big and visible.  But the if/else stuff is
> just ordinary blocks of text.

Not with syntax highlighting they're not ;) Seriously though, my guess
is even without syntax highlighting I'd still prefer it because I do
enough look-ahead and in 95% of cases the first 'if' is close enough to
the beginning of the line. In fact, most often plain assignments will be
much shorter than this construct so you can figure it out by combination
of line length and the 'if' keyword.

It still has the advantage over the more verbose version that I
mentioned before: you can see immediately that there's an assignment to
a single variable, and the logic flows like a single sentence in a
natural language.

>
>> That's where syntax highlighting comes in, as well.
>
> So basically, if we use syntax highlighting to make up for the legibility
> problems of a given syntax, then the syntax is okay, but people who don't
> use syntax highlighting to make up for its legibility problems are wrong.

That's not really true, it merely makes a given syntax easier to read
even when it's already a preferable syntax. It's like this, if someone
gives you five dollars for nothing, and then later gives you three
dollars, you don't complain that the latter amount is less than former :).

>
> I see.
>
> This does seem self-contained; you like syntax highlighting because you
> like constructs which are hard to read without it.  You like those constructs
> because they let you show off syntax highlighting.

Well, you're exaggerating this out of all proportion just to prove a
point. I like syntax highlighting in all of python and, in fact, in all
languages I've used. Even in crontab files! This is a single construct I
can think of, which, being already very readable, explicit, and
succinct, *on top of that*, gains even more in readability due to syntax
highlight.

So, as you can see, I'd like syntax highlight just fine if this
construct was not present in Python, and in fact I did. Conversely, I'd
prefer it to the longer version if there was no syntax highlight at all.

>
>> After some time getting used to it, I'd end up seeing this as:
>
>>    .
>>    .
>>    .
>>    if .. else:
>>    .
>>    .
>>    .
>
>> at first and then processing everything else.
>
> Assuming that the if/else was on the same page.  :)

I'll concede you one point in this case: if the statement 'x = .. if ..
else .. ' is split over two pages, I would at least seriously consider
the 'if: .. else: ' version. ;)

  -ak