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

Python best practices

fantascienza.net

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Python best practices

#31

Post by ken »

bayareaguy wrote: post #11

Most of that stuff is a bit silly but I learned python before it supported verbose regular expressions so I found this example useful. finder = re.compile(r""" ^ \s* # start at beginning+ opt spaces ( [\[\]] ) # Group 1: opening bracket \s* # optional spaces ( [-+]? \d+ ) # Group 2: first number \s* , \s* # opt spaces+ comma+ opt spaces ( [-+]? \d+ ) # Group 3: second number \s* # opt spaces ( [\[\]] ) # Group 4: clo…

I love regular expressions as much as anybody, but I never understood why people wrote code like that.

r"\s" is repeated 6 times in there, each time with a comment. Is there a reason nobody uses DRY when writing a regexp?

    spaces = r"\s*"
    number = r"([-+]?\d+)"
    bracket = r"([\[\]])"
    finder = re.compile(spaces.join(["^", bracket, number, ",", number, bracket, "$"]))

Re: Python best practices

#33

Post by spydez »

tdavis wrote: post #20

Always use 4 spaces as indent My god how I wish everyone did this... would make life so much easier.

What's wrong with 3?

IMO, indent is personal preference, and as long as you're 100% consistent, and stay away from the devil-spawn tab character, you're ok.

Re: Python best practices

#34

Post by etal »

yogipatel wrote: post #13

> if x is None: ... > if items is None: ... None's truth value is false, so the above are equivalent to: if x: ... if items: ... Empty sequences and mappings are also considered false, so you don't need to if len(items): ... Instead, you should if items: ... On a side note, does it annoy the hell out of anyone else that a sequence's length is len(foo) instead of foo.length() (or size, count, etc)?

Most of the builtins have a corresponding __magic_attribute__ for objects that support it: bool -> foo.__bool__, len -> foo.__len__, iter -> foo.__iter__. This is usually because some syntactic sugar or other built-in function/method relies on it being there. Example: "for x in foo" relies on foo having __iter__ (or an equivalent, maybe).

Re: Python best practices

#35

Post by bkovitz »

albertcardona wrote: post #30
BrandonM wrote: post #18

Earlier quoted context omitted.

The one place that I don't follow the guideline (unless it's the guideline and I just don't know it... it rarely comes up, so I haven't bothered to check) is on array indices. I do write: a[i+1]

Same here. I conceptualize it as part of a code compactness strategy: array indices are part of the same item, and thus I use syntax (like yours) that suggests inlining.

Same here, for the same reason.

Re: Python best practices

#36

Post by bkovitz »

tdavis wrote: post #20

Always use 4 spaces as indent My god how I wish everyone did this... would make life so much easier.

Awww, I like 3! 3 makes the tab levels very distinct, without wasting space. Of course it's just a matter of personal preference. But, is 4 really a widespread standard in the Python world?

Re: Python best practices

#37

Post by delackner »

ken wrote: post #31
bayareaguy wrote: post #11

Most of that stuff is a bit silly but I learned python before it supported verbose regular expressions so I found this example useful. finder = re.compile(r""" ^ \s* # start at beginning+ opt spaces ( [\[\]] ) # Group 1: opening bracket \s* # optional spaces ( [-+]? \d+ ) # Group 2: first number \s* , \s* # opt spaces+ comma+ opt spaces ( [-+]? \d+ ) # Group 3: second number \s* # opt spaces ( [\[\]] ) # Group 4: clo…

I love regular expressions as much as anybody, but I never understood why people wrote code like that. r"\s " is repeated 6 times in there, each time with a comment. Is there a reason nobody uses DRY when writing a regexp? spaces = r"\s*" number = r"([-+]?\d+)" bracket = r"([\[\]])" finder = re.compile(spaces.join(["^", bracket, number, ",", number, bracket, "$"]))

That is the most beautiful bit of RE I have seen in ages. Thank you.

I always do one-off RE transformations of text in vi or even just sed, but this alone is reason enough to start writing my more complicated RE one-offs in Python.

Re: Python best practices

#38

Post by danohuiginn »

bkovitz wrote: post #36
tdavis wrote: post #20

Always use 4 spaces as indent My god how I wish everyone did this... would make life so much easier.

Awww, I like 3! 3 makes the tab levels very distinct, without wasting space. Of course it's just a matter of personal preference. But, is 4 really a widespread standard in the Python world?

"is 4 really a widespread standard in the Python world?" yes. http://www.python.org/dev/peps/pep-0008/

Re: Python best practices

#39

Post by bkovitz »

danohuiginn wrote: post #38
bkovitz wrote: post #36

Earlier quoted context omitted.

Awww, I like 3! 3 makes the tab levels very distinct, without wasting space. Of course it's just a matter of personal preference. But, is 4 really a widespread standard in the Python world?

"is 4 really a widespread standard in the Python world?" yes. http://www.python.org/dev/peps/pep-0008/

I am so sad to see this. Thanks for posting it, though. Maybe I'll...ghhk..ekkk...switch. I went through the entire PEP and found that I'm following every other convention but two (multiple imports on one line, and I seldom write docstrings).

Re: Python best practices

#40

Post by cheponis »

spydez wrote: post #33
tdavis wrote: post #20

Always use 4 spaces as indent My god how I wish everyone did this... would make life so much easier.

What's wrong with 3? IMO, indent is personal preference, and as long as you're 100% consistent, and stay away from the devil-spawn tab character, you're ok.

I read a study that showed that 2,3, or 4-space indents were equivalent for readability. Therefore, I always use 2.
Post reply on HN