Python Best Practice Patterns

Re:Python Best Practice Patterns by collyw on Friday February 28, 2014 @12:49PM (#7320272)

Sometimes I find guidelines like these counterproductive.

For example, when looking through someone elses code, if it does not have deep levels of nesting I prefer longer methods you can read like a script rather than having to jump around the place to see what is each method.

Likewise with the 80 character guideline in PEP. It can take a lot longer to find the closing brace if it is hidden in columns that look like a newspaper article.

[ Parent | on HN ]

Re:Python Best Practice Patterns by bru on Friday February 28, 2014 @12:57PM (#7320323)

>Likewise with the 80 character guideline in PEP

Definitely. The PEP8 was actually revised 6 months ago[0]. Nothing crazy, but a bit more pragmatic.

>For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters)

0: text: http://legacy.python.org/dev/peps/pep-0008/#maximum-line-len...

commit : http://hg.python.org/peps/rev/fb24c80e9afb

[ Parent | on HN ]

Re:Python Best Practice Patterns by nine_k on Friday February 28, 2014 @03:42PM (#7321345)

I think this is due to poor naming, not due to short functions.

Compare:

  def makeMove(self, target):
    enemy_piece = target.piece
    if enemy_piece:
      self.takeEnemyPiece(enemy_piece)
    target.piece = self
    self.position = target

And

  def changeCoords(self, foo):
    if foo.standing_on_it:
      self.nowItsMine(foo.standing_on_it)
    foo.standing_on_it = self
    self.coords = foo

In the former case, you mostly don't need to consult the source of functions called. In the latter, you're never sure.

[ Parent | on HN ]

Re:Python Best Practice Patterns by gdulli on Friday February 28, 2014 @12:57PM (#7320328)

Yes. I look at these things and pick out what I think are the good parts.

[ Parent | on HN ]