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

11–20 of 97 posts

Re: Python Best Practice Patterns

#11

Post by Walkman »

lukasm wrote: post #7

I'm skeptical about the last one return None

I saw this code yesterday:

    def is_file_for(is_nagyker, type):
        if type == KIS_ES_NAGYKER:
            return True
        elif type == KISKER and not is_nagyker:
            return True
        elif type == NAGYKER and is_nagyker:
            return True
At the first glance, I thought it always return True. Would have been more clear an explicit return False at the end!

Re: Python Best Practice Patterns

#13

Post by famousactress »

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…

For certain use-cases (like constructing queries for an ORM) or other things where you're effectively passing around curried ideas to eventually be executed, I think cascading methods is a huge win.

Re: Python Best Practice Patterns

#14

Post by famousactress »

Walkman wrote: post #11
lukasm wrote: post #7

I'm skeptical about the last one return None

I saw this code yesterday: def is_file_for(is_nagyker, type): if type == KIS_ES_NAGYKER: return True elif type == KISKER and not is_nagyker: return True elif type == NAGYKER and is_nagyker: return True At the first glance, I thought it always return True. Would have been more clear an explicit return False at the end!

Seems rude to return None instead of False for an is_. I think I would have written:

    def is_file_for(is_nagyker, type):
         return type == KIS_ES_NAGYKER or \
   	    	(type == KISKER and not is_nagyker) or \
    	        (type == NAGYKER and is_nagyker)

Re: Python Best Practice Patterns

#15

Post by gdulli »

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…

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

Re: Python Best Practice Patterns

#17

Post by Walkman »

halflings wrote: post #10
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…

It seems he's using Python 3 (using print as a function), so no need to inherit object.

There is a print function in Python 2 either!

http://docs.python.org/2/library/functions.html#print

Re: Python Best Practice Patterns

#18

Post by atrk »

Several of these are generally applicable to programming:

* Keep functions small and composable

* Keep functions at a consistent level of abstraction

* Use constructors to ensure objects always exist in a complete, usable state

* Use meaningful method names in place of comments

It is nice to see that other people struggle with functions with lots of parameters + lots of partial state variables. I don't suppose anyone here has a better solution?

Re: Python Best Practice Patterns

#20

Post by collyw »

gdulli wrote: post #15
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…

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 a newspaper article.

Post reply on HN