[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 <ros...@gmail.com> wrote: > On Thu, Feb 21, 2019 at 11:09 AM Abe Dillon <abedil...@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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
