<div dir="ltr">[Chris Angelico]<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And this is always cited as the "obvious" solution.</blockquote><div><br></div><div>Yes. I think simon even referred to this "obvious" solution in his post when he said, "...which is a very common ocurence, <b>and doesn't warrant refactoring</b>"<br>So, my comment may have been unwarranted.<br><br>[Chris Angelico]<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The trouble is, unless "handle_it" has a name that tells you EVERYTHING about what it<br>does, you probably will end up having to go look at its definition -<br>which means a lot more flicking around.</blockquote><div><br>I think you're over emphasizing "EVERYTHING" and "probably". If your de-bugging or refactoring,<br>You typically have enough context to make an educated guess if you need to look deeper.<br><br>The Wikipedia for the game Tic-Tac-Toe (AKA Nots and Crosses) describes a <a href="https://en.wikipedia.org/wiki/Tic-tac-toe#Strategy">strategy</a><br><br>play(board, my_mark):<br><font face="monospace, monospace">    # Win<br>    moves = win(board, my_mark)<br>    if moves: return random.choice(moves)<br><br>    # Block<br>    moves = win(board, opposite(my_mark))<br>    if moves: return random.choice(moves)<br><br>    # Fork<br>    moves = fork(board, my_mark)<br>    if moves: return random.choice(moves)<br><br>    # Block Fork<br>    moves = fork(board, opposite(my_mark))<br>    if moves: return block_fork(moves, board, my_piece)</font></div><font face="monospace, monospace"><br>    # Center<br>    if board[1][1] is None: return (1, 1)<br><br>    # Corners<br>    moves = empty_corners(board)<br>    if moves: return random.choice(moves)<br><br>    # Sides<br>    moves = empty_sides(board)<br>    if moves: return random.choice(moves)<br><br># Failing test</font></div><div><font face="monospace, monospace">board = </font><span style="font-family:monospace,monospace">[['O' , None, None]</span><div><font face="monospace, monospace">         ['X' , 'X' , None]</font><br><font face="monospace, monospace">         [None, None, None]]</font></div><div><font face="monospace, monospace">mark = 'O'</font></div><font face="monospace, monospace">result = play(board</font><span style="font-family:monospace,monospace">, mark)</span></div><div><font face="monospace, monospace">expected = (1, 2)</font></div><div><font face="monospace, monospace">assert move == expected, f"Block! Expected: {expected}, Got: {result}"</font><br><br><font face="arial, helvetica, sans-serif">You don't need to know EVERYTHING about how </font><font face="monospace, monospace">block_fork</font><font face="arial, helvetica, sans-serif"> works to debug that failure. You<br>probably don't need to know EVERYTHING about how </font><font face="monospace, monospace">random.choice</font><font face="arial, helvetica, sans-serif"> works either. You don't<br>need to know about how most of the functions in the code work. The code is not blocking an<br>opponent's win. The fault must be in "</font><font face="monospace, monospace">win</font><font face="arial, helvetica, sans-serif">" or "</font><font face="monospace, monospace">opposite</font><font face="arial, helvetica, sans-serif">".<br><br> </font>[Chris Angelico]<font face="arial, helvetica, sans-serif"><br></font><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The cost of a long line has to be balanced against the cost of *avoiding* <br>having a long line. Splitting a line into consecutive lines has less cost than<br>breaking it out into a function, *unless* the function truly has its own meaning.</blockquote><div> </div><div>That's a good point. Pragmatism should always win the day, of course; and</div><div>excessive functional decomposition can cause it's own readability issues.<br>I only offer it as a strategy, not a flawless solution. Sometimes going beyond</div></div><div>80 columns is the most pragmatic choice, but such cases should be rare.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 6:23 PM Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Feb 21, 2019 at 11:09 AM Abe Dillon <<a href="mailto:abedillon@gmail.com" target="_blank">abedillon@gmail.com</a>> wrote:<br>
><br>
> [simon.bordeyne]<br>
>><br>
>> I find that 100 to 120 characters is ideal as far as line length goes.<br>
><br>
> Your finding goes against a long history of people attempting to present text in the most readable way possible.<br>
> AFIK, the human fovea hasn't grown much larger in recent years.<br>
<br>
You can't see the entire line in focus simultaneously anyway, so the<br>
line length is about how far you can flit your eye left to right, not<br>
the actual fovea itself.<br>
<br>
> [simon.bordeyne]<br>
>><br>
>>  On top of that, it's not uncommon to reach 6, even 7 indentation levels.<br>
><br>
> It should be pretty uncommon. You might want to re-think your coding style if you're regularly writing code that's so deeply indented.<br>
> A good trick is to use helper functions:<br>
><br>
> #instead of this<br>
> if condition:<br>
>     ...code<br>
><br>
> #do this<br>
> if condition:<br>
>     handle_it()<br>
<br>
And this is always cited as the "obvious" solution. The trouble is,<br>
unless "handle_it" has a name that tells you EVERYTHING about what it<br>
does, you probably will end up having to go look at its definition -<br>
which means a lot more flicking around. The cost of a long line has to<br>
be balanced against the cost of *avoiding* having a long line.<br>
Splitting a line into consecutive lines has less cost than breaking it<br>
out into a function, *unless* the function truly has its own meaning.<br>
<br>
ChrisA<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>