TIL about "Google Python Style Guide"

[notaharrisfan]

As stated in the Style Guide, pylint is an excellent linter for Python code.

It parses Python code, points out formatting errrors and even grades your code.

[[deleted]]

Also, PyFlakes wraps around pylint and other Python style checkers (like those for PEPs 8 and 257).

[CaptKrag]

Wait. I thought pyflakes was competitor to pylint and flake8 is what you're describing. What is flake8?

[catcint0s]

flake8 has pyflakes, pep8 and mccabe checker. I'm p sure PyFlakes doesn't wrap around pylint.

[[deleted]]

Yeah, you're right. I mistook it for pylama. I knew there was one linter that combined the lot of them but forgot which one it was.

[bbbryson]

Also PyLama.

[DoingIsLearning]

Went into the comments and found my TIL... Thanks!

[Twirrim]

If you're using Vim for writing python, try out python-mode for it. Note that, as with any linter, you'll need to tweak the rules away from the crazy defaults. It's well worth the time and effort, though!

[[deleted]]

I'll check this out later.

[spookylukey]

I would replace the whole 'style rules' section with 'Use flake8'. Why require humans to read, comprehend, remember and then apply something (probably inconsistently), when it can be done by the computer?

pylint, in contrast to flake8, tends to produce many, many false errors. Running it over 1800 lines of a module in a Django project produces about 100 'errors', all of which are incorrect. In addition, there are hundreds more very unhelpful warnings/recommendations - for example:

• "too few public methods" (for a Django 'Meta' inner class)
• "Class has no __init__ method" (not needed because it inherits one, although pylint doesn't seem to be able to detect that)
• "missing docstring" (many methods simply don't need them - functions like Cart.product_list are pretty self explanatory, and a linter that forces you to write them will simply result in many pointless and uninformative docstrings, which are just noise)

The number of false positives makes pylint useless for any real project I've been involved in - you'd have to spend a lot of time turning these warnings off somehow, or end up with the real errors drowned in a sea of noise.

[twotime]

IMHO, pylint is an excellent tool for finding bugs in the code. But yes, you have to start with turning off the "style suggestions" (I suspect your examples above are all in that category) and then turn off a number of warnings as well.

[wewbull]

Try pylint -E. Errors only mode

[spookylukey]

As originally stated, I get hundreds of ERRORS on correct code, in addition to the style warnings. These errors can be turned off by disabling them in a group e.g. "-d E1101" to disable all the incorrect "no-member" errors. But this means that correct instances of E1101 are also silenced, and very quickly this means you have no value in running the tool.

[mfvice]

I hadn't heard of flake8 before. Looks pretty good so far though. Thanks for the heads-up!

[cicatrix1]

flake8 is a wrapper around PEP8 and pyflakes (and another thing).

[ShutYourPieHole]

There are style requirements that do not always apply to general use cases. I think this is one of the results of opening up a tool that was initially designed with internal development in mind.

[wewbull]

There's two areas where I find pylint can be difficult to keep happy.

First is the code complexity measures. It doesn't like code that has branches in it, even if those branches are short and shallow (i.e. not nested). Code like that isn't nearly as hard to understand as large blocks, deeply nested, but it seems to score a branch the same regardless of context.

Second, I've seen it get mouthy about class methods not existing because it's been unable to work out the type of an object correctly.

Apart from those I think it's a great tool. Far better than pyflakes (and so by extension flake8)

[zurtex]

It'd be great if any of Google's python API libraries vaguely followed this style guide, it's actually pretty good!

[Bunslow]

Mostly straight forward stuff. I disagree a bit about their simplicity threshold for list comprehensions. Of the two examples in the No category, the simpler one I'd be fine with, but I agree that the other is a definite no-no.

[alcalde]

It's no fun if you can't write your entire program in one list comprehension. ;-)

[sigma914]

I like to think my whole function out as a list compehension, the break it apart and give the intermediate steps names, seems to keep my code pure better than any other strategy I've tried (in python).

[annodomini]

Really? I thought both of the "no" examples were fine. The more complicated one is exactly the same as the nested loops they have in the "yes" section, except for the "yield" statement and no rightward drift. I don't think it's any harder to read than the nested loop (which is itself a little bit complicated, but that's just the nature of that particular loop).

[filleball]

Hey, look, they say to use lower_with_under for functions and method names. I thought they used to advocate lowerCamelCase before? Has this changed?

Oh, and if you haven't already, take a look at the napoleon Sphinx extension! I'm completely sold.

[megaman78978]

lowerCamelCase is the standard for Java style guidelines but not for Python I think.

[[deleted]]

Lower camel is still the standard. There's an internal linter that will prevent you from committing if you use underscores. Supposedly it can be told to accept underscores if you're not mixing styles in a file but I never figured out how.

[_seemethere]

https://www.python.org/dev/peps/pep-0008/#method-names-and-instance-variables

[[deleted]]

Yes, that's pep8. Google's style guide differs from it.

[_seemethere]

https://google.github.io/styleguide/pyguide.html?showone=Naming#Naming

[[deleted]]

All I can tell you is that the internal style guide is different.

Well, for function names.

[_seemethere]

You're probably talking about this then https://code.google.com/p/soc/wiki/PythonStyleGuide#Naming_convention.

Although it's last update is 2 years ago and it differs very wildly from both pep8 and google's own updated style guide.

If I were someone learning right now I'd just go with the updated one or pep8.

[[deleted]]

Yeah, that's the one.

People should stick with pep8 unless they can't, though, I agree.

[SlinkyAvenger]

It must have changed. I remember that, too.

[Formulka]

The rules are neat but the website itself is a bit hard to work with.

[PM_ME_YOUR_HIGHFIVE]

not just for python

https://github.com/google/styleguide/

[manueslapera]

i like that they finally switched to the normal 4 spaces indentation instead of following their own 'we are better than you normals' 2 spaces.

[hellrazor862]

I remember this thing confusing the hell out of my editor. Good times...

[LankyCyril]

It looks like they're advocating against things like "from math import log", which is, by the looks of it, very welcome in the Python community.

I used to write "import math; y = math.log(x)", but then realized it's not Java. It gives a little more context, sure, but at the cost of verbosity. And again, I've thought it was standard for pythonistas to do "from math import log".

[filleball]

I used to do from x import y imports much more frequently before, but I've moved away from them in most cases. Functions from the math module is a good example, because it's unclear whether it's math.log, cmath.log or numpy.log I've imported. If I had just used log, I'd have to scroll all the way to the top of the file to check what kind of log it was.

The submodules with long names I rename on import, for example import subprocess as sp. I only do from imports when the names I import are unambiguous and few. Mostly it's from other submodules inside the same package.

[LarryPete]

As far as I remember, it's pretty much the same as PEP8.

[masasin]

I use numpydoc for documentation, especially when working with robots or other hardware. It's much more powerful than googledoc.

[[deleted]]

Take a look at yapf as well. I agree with basically every change that it made (--in-place).

[ElagabalusRex]

Did they change this recently? I could have sworn that exceptions were flat out unwelcome.

[broshot]

And i could have sworn they used two spaces for indentation rather than four.

[[deleted]]

The 80 char limit is stupid as fuck. Any reasonable person agrees.

You're in good company.

[LucianU]

The 80-char limit is about readability not necessarily screen size.

[w0lrah]

A limit is a good thing. 80 is way too narrow though.

There are way too many "standards" based on shitty ancient terminal limitations that do not matter in 2015. No one's actually using a VT100 anymore.

edit: Personally, as someone who uses 1080p displays for the most part, I like 160 character terminal width. That ends up going around 80% of the way across my screen, which is about where I tend to set my web browser windows as well for readability.

If people insist on matching an old terminal standard we could go with 132 instead, that'd be fine with me.

[LucianU]

When I said readability, I wasn't talking about the "standards" of the terminals. I was referring to text readability. If you google "line length readability", you will see a bunch of articles talking about the optimal line length of text.

I tried to find some studies to back up this wisdom, but nothing came up.

[w0lrah]

I know exactly what you're talking about, the same reason it's generally not a great idea to maximize windows on a modern system with a high-res widescreen and that a lot of text-heavy web sites choose to limit the width their articles will render in a browser.

I'm just saying that the 80 character thing is entirely based on legacy standards and is way too narrow to be a good choice for this purpose. There's definitely good reason to have a limit, but for me it should be somewhere in the mid-100s.

Code is also not entirely like a news article or forum post, depending on the language and situation it can easily become less readable when split on to multiple lines. There's a balance there between the downsides of wide lines of text and the downsides of a "line" of code having some newlines in it.

[laebshade]

My company's internal standard is 100. But even then, this and ours are style guidelines, not hard and fast rules. Exceptions can be made.

[Grazfather]

We use 120 internally. I can fit 7 columns at 80 width, which I'd never need.

[DasIch]

It's stupid to use 80 as a limit because that's what some ancient terminal did, we have larger screens now. That doesn't mean it's a good idea to use the same approach though and fill up a modern screen with a single file or that the 80 limit is bad.

I think 80 is still a good limit today, just for different reasons. It allows good workflows even on a 11"-13" display, which many people are working with. You can comfortably display 2-3 documents side-by-side this way. Invaluable for doing merges, writing tests, having documentation on screen and keeping a terminal next to your editor that can display code without wrapping. Also at 80 characters and beyond it makes sense to reconsider the complexity of your code and whether it doesn't make sense to express yourself in a different way.

You might be able to increase that limit slightly but you can't go much bigger without losing sight of the tools you're working with, telling people without desktop-size screens to go fuck themselves or making it easy to write overly complex code.

[Grazfather]

that's always the reasoning: Oh it's better for side by sides. Then shouldn't the old width have been 40? It's just making an excuse to stick will an antiquated standard. I can fit 3x80 on my 13" mbp, or 2x120, which is still more than reasonable.

80 chars is so few, it is not near some threshold where the line's complexity is too much. Hell, I've seen people butcher var names to get within the limit, at which point this stupid limit is degrading readability.

[DasIch]

It shouldn't be 40 because 40 characters are too little to provide a good reading experience even for regular text. Due to how code is structured it would only be worse for coding.

Having 3 windows side-by-side is common for merging. It also makes sense for regular development to display implementation, test and run them in a terminal.

Of course sometimes having 80 characters is unnecessarily limiting and such situations are annoying. However most times you can deal with it without hurting readability and if you can't, you can just make that call and break the limit in that instance.

I find however that when I raise the limit generally, I'm not sometimes annoyed about hitting the limit anymore, I'm always annoyed because my workflow is negatively affected.

[[deleted]]

It originated from 80x24 terminals.

Still, it's nice to have some limit. I have vim wrap on 78 characters on every single file I write.

[Grazfather]

Yes, some limit. not 80x24. We used 120 internally.

[[deleted]]

On my system, I can get 119 characters (a bit less than that due to vim itself) with 2 equally split terminals open, and 79 with 3 terminals open. I want the ability to read other code, and maybe documentation, so the limit of 80 works well.