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

Python Style Guide from Google

google.github.io

Post reply on HN
Print view View original

21–30 of 30 posts

Re: Python Style Guide from Google

#21

Post by catnaroek »

adrianratnapala wrote: post #17
jsolson wrote: post #13

Earlier quoted context omitted.

It has improved considerably since the adoption of (much of) C++11. Still no exceptions, though.

The advantage of exceptions is not so much their "expressive power", but the fact that they provide an approximation to error handling even when nobody remembers to express it. If my team had some process (via code review, static analysis, or anything else) that could ensure error returns were actually checked and handled, then the case for exceptions would be much diminished.

> some process

Or something like Rust's `Result` type? You can't possibly forget to `match` it, and if you `unwrap` it, it will be plain obvious, both to humans and to linters.

http://doc.rust-lang.org/std/result/index.html

Re: Python Style Guide from Google

#23

Post by adrianratnapala »

Hermel wrote: post #22

The only rule that would bother me is the max line width of 80 characters. Why still stick to this rule with today's screens? I usually set this to 200.

Just because you have a screen that can display an enourmously long line of text, it doesn't mean that text is going to be readable. Or that you want to use the whole width of your screen for displaying unreadable text.

Lines longer than 100 chars are very rare in readable code. And it is easy to break lines down to 80 or even 72. If you do that, then it becomes easy to place two windows of good sized text side-by-side.

Re: Python Style Guide from Google

#24

Post by strajk »

m_mueller wrote: post #19

One thing I find odd is to prohibit classes / functions from being imported, instead forcing to always write their module names for the fear of namespace collisions. Is this common for Python in organisations? Did I get something wrong? Seems to a little bit too much on the Java side of this tradeoff.

I prefer importing whole modules too. One of the benefit is much easier code reviews:

Imagine this diff in the middle of a file (in Javascript)

  if (includes(users, userId)) {
    open(load(userId))
  }
vs

  if (_.includes(users, userId)) {
    Modal.open(UserApi.load(userId))
  }

Re: Python Style Guide from Google

#25

Post by ju-st »

m_mueller wrote: post #19

One thing I find odd is to prohibit classes / functions from being imported, instead forcing to always write their module names for the fear of namespace collisions. Is this common for Python in organisations? Did I get something wrong? Seems to a little bit too much on the Java side of this tradeoff.

Code with many from... imports becomes very unreadable very fast.

Re: Python Style Guide from Google

#28

Post by jfoster »

jdboyd wrote: post #11
mozumder wrote: post #5

4 spaces? seriously? Why would anyone type out 4 spaces instead of one tab?

Virtually everyone does type one tab and uses a text editor that expands the tab to four spaces in the file.

Yep. I've never really understood why editors tend to replace the tab with spaces, though. It seems to work pretty much the same when indenting, but involves more backspacing and introduces more potential for error (eg. deleting 3 spaces instead of 4) when deleting.

What is the advantage that spaces have over tabs?

Re: Python Style Guide from Google

#29

Post by BerislavLopac »

jfoster wrote: post #28
jdboyd wrote: post #11

Earlier quoted context omitted.

Virtually everyone does type one tab and uses a text editor that expands the tab to four spaces in the file.

Yep. I've never really understood why editors tend to replace the tab with spaces, though. It seems to work pretty much the same when indenting, but involves more backspacing and introduces more potential for error (eg. deleting 3 spaces instead of 4) when deleting. What is the advantage that spaces have over tabs?

They ensure uniformity regardless of how your editor is set up. E.g. the default vim setting is to display tabs as eight spaces, which means that viewing a file with tabs (or, even worse, a mixture a tabs or spaces) will look differently if viewed on a newly-set server than in my regular IDE (which is set to display a tab as four spaces).

Re: Python Style Guide from Google

#30

Post by andkenneth »

jfoster wrote: post #28
jdboyd wrote: post #11

Earlier quoted context omitted.

Virtually everyone does type one tab and uses a text editor that expands the tab to four spaces in the file.

Yep. I've never really understood why editors tend to replace the tab with spaces, though. It seems to work pretty much the same when indenting, but involves more backspacing and introduces more potential for error (eg. deleting 3 spaces instead of 4) when deleting. What is the advantage that spaces have over tabs?

Atom at least treats soft tabs as tabs for the most part, when you backspace into a soft tab it will delete all 4 spaces at once.
Post reply on HN