[Python-ideas] PEP 8 update on line length

[Abe Dillon]

[Chris Angelico]
>
> And this is always cited as the "obvious" solution.


Yes. I think simon even referred to this "obvious" solution in his post
when he said, "...which is a very common ocurence, *and doesn't warrant
refactoring*"
So, my comment may have been unwarranted.

[Chris Angelico]

> The trouble is, unless "handle_it" has a name that tells you EVERYTHING
> about what it
> does, you probably will end up having to go look at its definition -
> which means a lot more flicking around.


I think you're over emphasizing "EVERYTHING" and "probably". If your
de-bugging or refactoring,
You typically have enough context to make an educated guess if you need to
look deeper.

The Wikipedia for the game Tic-Tac-Toe (AKA Nots and Crosses) describes a
strategy <https://en.wikipedia.org/wiki/Tic-tac-toe#Strategy>

play(board, my_mark):
    # Win
    moves = win(board, my_mark)
    if moves: return random.choice(moves)

    # Block
    moves = win(board, opposite(my_mark))
    if moves: return random.choice(moves)

    # Fork
    moves = fork(board, my_mark)
    if moves: return random.choice(moves)

    # Block Fork
    moves = fork(board, opposite(my_mark))
    if moves: return block_fork(moves, board, my_piece)

    # Center
    if board[1][1] is None: return (1, 1)

    # Corners
    moves = empty_corners(board)
    if moves: return random.choice(moves)

    # Sides
    moves = empty_sides(board)
    if moves: return random.choice(moves)

# Failing test
board = [['O' , None, None]
         ['X' , 'X' , None]
         [None, None, None]]
mark = 'O'
result = play(board, mark)
expected = (1, 2)
assert move == expected, f"Block! Expected: {expected}, Got: {result}"

You don't need to know EVERYTHING about how block_fork works to debug that
failure. You
probably don't need to know EVERYTHING about how random.choice works
either. You don't
need to know about how most of the functions in the code work. The code is
not blocking an
opponent's win. The fault must be in "win" or "opposite".

 [Chris Angelico]

> The cost of a long line has to be balanced against the cost of *avoiding*
> having a long line. Splitting a line into consecutive lines has less cost
> than
> breaking it out into a function, *unless* the function truly has its own
> meaning.


That's a good point. Pragmatism should always win the day, of course; and
excessive functional decomposition can cause it's own readability issues.
I only offer it as a strategy, not a flawless solution. Sometimes going
beyond
80 columns is the most pragmatic choice, but such cases should be rare.

On Wed, Feb 20, 2019 at 6:23 PM Chris Angelico <rosuav at gmail.com> wrote:

> On Thu, Feb 21, 2019 at 11:09 AM Abe Dillon <abedillon at gmail.com> wrote:
> >
> > [simon.bordeyne]
> >>
> >> I find that 100 to 120 characters is ideal as far as line length goes.
> >
> > Your finding goes against a long history of people attempting to present
> text in the most readable way possible.
> > AFIK, the human fovea hasn't grown much larger in recent years.
>
> You can't see the entire line in focus simultaneously anyway, so the
> line length is about how far you can flit your eye left to right, not
> the actual fovea itself.
>
> > [simon.bordeyne]
> >>
> >>  On top of that, it's not uncommon to reach 6, even 7 indentation
> levels.
> >
> > 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.
> > A good trick is to use helper functions:
> >
> > #instead of this
> > if condition:
> >     ...code
> >
> > #do this
> > if condition:
> >     handle_it()
>
> And this is always cited as the "obvious" solution. The trouble is,
> unless "handle_it" has a name that tells you EVERYTHING about what it
> does, you probably will end up having to go look at its definition -
> which means a lot more flicking around. The cost of a long line has to
> be balanced against the cost of *avoiding* having a long line.
> Splitting a line into consecutive lines has less cost than breaking it
> out into a function, *unless* the function truly has its own meaning.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190220/623eb1db/attachment.html>