Live data from Hacker News

Python Style Guide from Google

google.github.io

11–20 of 30 posts

Re: Python Style Guide from Google

#13
post #2

Google's C++ style guide is much more interesting: https://google.github.io/styleguide/cppguide.html

In that it destroys a greater proportion of the language's expressive power? :-p

It has improved considerably since the adoption of (much of) C++11.

Still no exceptions, though.

Re: Python Style Guide from Google

#15
post #5

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

(The last episode of Silicon Valley referenced the tabs vs. spaces debate with exaggerated examples of hitting the space bar four times to indent. This probably isn't a serious question.)

Re: Python Style Guide from Google

#16
post #5

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

There's that balance between readability and being able to operate in highly nested structures and for loops while all kinds of matrix multiplication in AI/ML for example. Minimizing wrapping is important here and you do with 4 spaces, not 8.

Re: Python Style Guide from Google

#17
post #13

Earlier quoted context omitted.

In that it destroys a greater proportion of the language's expressive power? :-p

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.

Re: Python Style Guide from Google

#18
post #8
post #5

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

Personally, i use tabs of size four with expandtabs setting. That way i don't have to press four spaces and my files look the same across all editors and platforms.

I thought everybody does that..who the hell would type space 4 times?

Re: Python Style Guide from Google

#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.

Re: Python Style Guide from Google

#20
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.

I mostly agree. We do have that in the form of static analysis, Status and StatusOr return types, and MUST_USE_RESULT (which is also visible in external codebases like V8). There's still a fair amount of boilerplate, but on the other hand control flow transfers are explicit, so it's a trade-off.
Post reply on HN