Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python Best Practice Patterns

stevenloria.com

Post reply on HN
Print view View original

51–60 of 97 posts

Re: Python Best Practice Patterns

#51

Post by SoftwareMaven »

Having gone through a couple thousand lines of Javascript that adhered to the "keep methods small", I call bollocks on that. Make methods as big as they need to be.

    function doFooOnList(l) {
        for (var i=0; i
gets old, very quickly.

After designing and building code for 20+ years, I can comfortably say that there are no arbitrary rules of software design, and some of the worst code I've seen has been a result of following "best practices" instead of thinking for oneself.

Write code like it is meant to be read, because that's what happens most often.

Re: Python Best Practice Patterns

#52

Post by nine_k »

bru wrote: post #9

Several of those patterns are incomplete or frowned upon: * if a method does not use the object's state (no `self` usage) make it a `class-` or `staticmethod`. * Some magic methods are presented. There's more to them[0]. * one should not write `class MyClass:` but `class MyClass(object):` (new style class[1]) * the last one (`return None`) make me very dubious * Cascading methods: that's a big no . The idiom is that…

Cascading methods aka fluid interface are OK in many cases, e.g. various builders. OTOH immutable objects are preferable in many cases.

What I really disliked is storing intermediate results of a multi-stage computation in instance variables. It is so easy to return multiple values from Python functions. Also, thinking what you need and need not pass and return between interconnected functions helps structure them much better, into smaller, clearer pieces (as #1 correctly advises).

Re: Python Best Practice Patterns

#53

Post by jcampbell1 »

SoftwareMaven wrote: post #51

Having gone through a couple thousand lines of Javascript that adhered to the "keep methods small", I call bollocks on that. Make methods as big as they need to be. function doFooOnList(l) { for (var i=0; i gets old, very quickly. After designing and building code for 20+ years, I can comfortably say that there are no arbitrary rules of software design, and some of the worst code I've seen has been a result of follow…

You are calling bollocks on a claim he doesn't make.

Re: Python Best Practice Patterns

#54

Post by nine_k »

SoftwareMaven wrote: post #51

Having gone through a couple thousand lines of Javascript that adhered to the "keep methods small", I call bollocks on that. Make methods as big as they need to be. function doFooOnList(l) { for (var i=0; i gets old, very quickly. After designing and building code for 20+ years, I can comfortably say that there are no arbitrary rules of software design, and some of the worst code I've seen has been a result of follow…

`for (var i=0; iSame applies to Python, BTW; get used to list comprehensions and generators and you cannot look back.

Re: Python Best Practice Patterns

#55

Post by nine_k »

euphemize wrote: post #27
bru wrote: post #9

Several of those patterns are incomplete or frowned upon: * if a method does not use the object's state (no `self` usage) make it a `class-` or `staticmethod`. * Some magic methods are presented. There's more to them[0]. * one should not write `class MyClass:` but `class MyClass(object):` (new style class[1]) * the last one (`return None`) make me very dubious * Cascading methods: that's a big no . The idiom is that…

> * the last one (`return None`) make me very dubious I'm curious, as someone who uses this pattern quite a bit, how would you improve on this?

There are no procedures, only functions that return something. A function either returns something explicitly, or returns None. Easy.

Re: Python Best Practice Patterns

#56

Post by famousactress »

DasIch wrote: post #47
famousactress wrote: post #43

Earlier quoted context omitted.

> Splitting hairs. Severely, since what you're doing is mutating the actual state-data of the query object.

In the case of SQLAlchemy you are not. The cascading methods on query objects create new query objects as it should be. Mutating objects with cascading methods is horrible API design as it suggests immutability where there is none.

Oh right, that's fair. Same in Django (and you're right, mutation in this case would be horrible design), I suppose I was mixing the metaphorical with the actual.

Re: Python Best Practice Patterns

#57

Post by nine_k »

collyw wrote: post #20
gdulli wrote: post #15

Earlier quoted context omitted.

These things turn subjective pretty quickly. That, and, "this is the way most people do it, so just do it this way."

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…

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.

Re: Python Best Practice Patterns

#59

Post by pekk »

nine_k wrote: post #54
SoftwareMaven wrote: post #51

Having gone through a couple thousand lines of Javascript that adhered to the "keep methods small", I call bollocks on that. Make methods as big as they need to be. function doFooOnList(l) { for (var i=0; i gets old, very quickly. After designing and building code for 20+ years, I can comfortably say that there are no arbitrary rules of software design, and some of the worst code I've seen has been a result of follow…

`for (var i=0; i Same applies to Python, BTW; get used to list comprehensions and generators and you cannot look back.

These aren't supported everywhere in javascript.

Re: Python Best Practice Patterns

#60

Post by nine_k »

pekk wrote: post #59
nine_k wrote: post #54

Earlier quoted context omitted.

`for (var i=0; i Same applies to Python, BTW; get used to list comprehensions and generators and you cannot look back.

These aren't supported everywhere in javascript.

jQuery or underscore provide them on every sane JS platform. These are not hard to write by hand, too.
Post reply on HN