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

21–30 of 97 posts

Re: Python Best Practice Patterns

#21

Post by Goopplesoft »

famousactress wrote: post #13
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.

Yeah these things aren't as black and white as both the blogger and the original commenter make it seem. Software design is very subjective.

Re: Python Best Practice Patterns

#22

Post by collyw »

atrk wrote: post #18

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…

Comments should explain why you are doing something while method names are a guide to what they are doing. I see them as for different purposes and one should not replace the other.

Re: Python Best Practice Patterns

#23

Post by collyw »

atrk wrote: post #18

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…

I was playing about in Django recently, having written previous views as functions, I wrote some new ones as class based views. I felt that the OOP approach kept it cleaner and inheritance could be used in the same way as currying could for the function based views (but less complex - maybe because I understand OOP concepts better).

Re: Python Best Practice Patterns

#24

Post by bru »

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…

>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

Re: Python Best Practice Patterns

#25

Post by gdulli »

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…

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

Re: Python Best Practice Patterns

#27

Post by euphemize »

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?

Re: Python Best Practice Patterns

#28

Post by IgorPartola »

Agree with all of these but two. The first is the example of doing:

    class Foo(object):
        highlight = reverse
No, that is not clearer. Now I have no idea what this method does. Making it explicit requires more keystrokes, but allows you to properly document the method. Also, when I run help(Foo.highlight) I won't get the generic documentation for `reverse`.

Second, using `each` for a generic iteration variable. This is an opinion, not a best practice. I would argue that either the loop is a one liner, at which point use whatever you want (x works well), or it's more than one line and then I want a proper name for the thing you are iterating over.

Re: Python Best Practice Patterns

#29

Post by MereInterest »

famousactress wrote: post #14
Walkman wrote: post #11

Earlier quoted context omitted.

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)

As another change, it is recommended to avoid explicit line continuations by using parentheses instead.

    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))
This way, it doesn't break if there is extra whitespace at the end of the line.
Post reply on HN