veky
on Jan. 29, 2015, 1:55 p.m.
<p>Despite appearances, I do care about readability. But do you <em>really</em> think that what you wrote is more <em>readable</em> than what I wrote above? I'd very much want to know why you think so. Here is an overview of why I don't:</p>
<p>In my code, it's obvious where the containment is checked. You just look to the left of the dot, and see it's a `lower()` of something. Continuing looking it that direction, you see that it's `text.lower()`. Since `text` is the (only) parameter, that's enough information to conclude everything you need to know.</p>
<p>In your code, a reader first sees `text.<strong>contains</strong>`. Now they have two choices, they can be optimistic and start looking at the top, find `text` as a parameter, and come <em>quickly</em> to the <em>wrong</em> conclusion that it's the same `text`.</p>
<p><em>Or</em> they can be pessimistic, and start reading the code up towards the beginning, trying to see where `text` is really last bound. There they find that it's actually `.lower()` of a previous text, and continuing reading up, come <em>slowly</em> to the <em>correct</em> solution that it's the `lower()` of a passed argument where the containment is checked.</p>
<p>In the first case, the conclusion is wrong; in the second, process is noticeably slower than when reading my code. Now let's see why you consider your version more readable. :-...</p>

DmitriyS
on Jan. 30, 2015, 5:21 p.m.
<p>As mentioned above, this code is more readable for me. Being a beginner I start to read this function with arguments, then go to first line and see that some `text` is transferred to lowercase. Next line works with lowered text - ok, I remember that. And so on.
Even if <em>text.lower().contains</em> is quite simple to read, I don't like complex calls such as <em>something[dot]some</em>call()[dot.again]other<em>call()[one.more.dot]endless</em> where it <strong>can be</strong> written (and then read) simpler.
Maybe one day I'll become an advanced python-coder and say: "That's obvious :)"</p>

veky
on Jan. 30, 2015, 7:34 p.m.
<blockquote>
<p>ok, I remember that. </p>
</blockquote>
<p>Yes, you do. But my point is that you don't <em>need</em> to remember. It can be even <em>easier</em>. :-)</p>
<hr />
<p>`something[dot].some<em>call()[dot.again].other</em>call()[one.more.dot].endless` is obviously hyperbole. There is a nice conventional limit of 80 characters per line. And since you obviously have to <em>do</em> something with that value, and indent it a few 4char tabs, you're over that.</p>
<p>But even so, let's assume that your example, for educational value, is real. We both agree it's unreadable. What you claim (from my perspective) is that it would be <em>more</em> readable if it was written</p>
<pre class='brush: python'>something = something[dot]
some_call = something.some_call
some_call = some_call()
dot = dot.again
something = some_call[dot]
other_call = something.other_call
other_call = other_call()
more = one.more
dot = more.dot
something = other_call[dot]
something.endless
</pre>
<p>I <em>hope</em> you see the problem very clearly now. Complexity is the same, writing it vertically instead of horizontally is doing precisely nothing. And, more importantly, reusing names is just adding insult to injury.</p>
<p>The <em>reason</em> you find vertical version in the solution readable is the <em>same</em> reason you find `text.lower().<strong>contains</strong>` "quite simple to read". Nothing lost, but nothing gained either.</p>
<p>The <em>reason</em> people write code vertically (sequentially) instead of horizontally is to give meaningful <em>names</em> to parts of computation, that would enable easier understanding. By reusing names, you're squandering that opportunity.</p>