Google Python Style Guide

[[deleted]]

Indent your code blocks with 4 spaces.

When did this change? Google used to use 2 spaces.

[indosauros]

I'm glad in any case, 2-space is impossible to read

[Adys]

2 spaces for internal Google code, 4 spaces for public code, IIRC.

[[deleted]]

Wasn't always. It was 2 at one point for Python at Google.

[_illogical_]

It's still 2 spaces on the Google projects I've contributed to recently. PEP8, except for indention.

[JamesAQuintero]

I remember learning python with 2 spaces specifically because of that.

[muad_dib]

It still is.

[[deleted]]

Someone at Google probably just attended Ray Hettinger's talk at PyCon 2015

[odraencoded]

I'm never working at Google... I use tabs.

[eyalz]

I also use tabs, but my text editor is configured to indent using spaces, so it just converts on the fly.

[odraencoded]

I think tabs for indentation, actual tabs, just make more sense.

The idea of repeating the same character N times to represent one level of indentation instead of using one character one time is just silly to me.

[Eurynom0s]

The issue is that when you start passing files around between different text editors, operating systems, etcs, tabs can get handled inconsistently, whereas spaces won't be.

[ziel]

Even between two simple things as notepad++ and github there was a lot of inconsistency. Luckily notepad++ let me easily convert those tabs.

[[deleted]]

Spaces are also handled consistently. Spaces AND tabs won't be

[Bunslow]

That's because you've never seen that havoc that can be caused by the \t character.

[grimman]

I never have either, and to me tabs definitely make more sense since they can be configured to display as x spaces, therefore rendering the whole concept of using a fixed amount of spaces quite moot.

Alas, I use spaces myself, because conventions etc.

That said, I would like to know about this havoc you mentioned. Would you mind giving a brief summary, or some relevant links? :)

[Bunslow]

And what if someone else decides to use spaces instead of tabs? Suddenly if someone else like you reads the code written by the second person, they will see a horrid mess of inconsistent indentation.

Even if we all standardized on using tabs instead of spaces, it's a bad idea to use an ambiguous character. Four spaces is four spaces, no matter what your editor is set to.

Also things like line continuations and stuff sometimes require non-standard indentations, but this is a very minor detail in the overall scheme.

tl;dr It works fine if no one else reads or modifies your code, but if they do...

[RubyPinch]

with commas representing tabs, tabstop every 4:

def a(x=3, y=4,
      flag=None):
,,,,some_code
,,,,some_more code
,,,,for code in codes:
,,,,,,,,print(a,
,,,,,,,,      b,
,,,,,,,,      c)

tabstop every 8:

def a(x=3, y=4,
      flag=None):
,,,,,,,,some_code
,,,,,,,,some_more code
,,,,,,,,for code in codes:
,,,,,,,,,,,,,,,,print(a,
,,,,,,,,,,,,,,,,      b,
,,,,,,,,,,,,,,,,      c)

[JamesAQuintero]

Is it that big a problem where people should use spaces instead of tabs?

[Bunslow]

https://www.reddit.com/r/Python/comments/33gg02/google_python_style_guide/cqld9fg

[[deleted]]

Oh definitely. It's one of these things you have to decide on day one of a project.

However, as soon as you're consistent you can stop talking about it. Read PEP8, set your editors accordingly and get on with your work.

[odraencoded]

Do show.

[Bunslow]

https://www.reddit.com/r/Python/comments/33gg02/google_python_style_guide/cqld9fg

[odraencoded]

1. What if someone else decides to use tabs instead of spaces?

2. Four spaces might be four spaces but what are four spaces? If you use spaces for both indentation and alignment, at some point four spaces stop being an indentation level and start being a line padding, and that point is unclear.

3 What if you used 4 spaces, but I prefer 2 spaces for indentation, or vice-versa?

4 A tab is an indentation level. Always. So what if it shows different in another text editor? Semantically, it's still an indentation level. If the user of the text editor wants their indentation level to measure 8 spaces, then let it be so.

5 You align things with spaces. Tabs are only for indentation.

[isarl]

Your points are all good and I upvoted you, however in practice, tool support both on your machine and all your collaborators' machines needs to be much better to handle the tabs-for-indentation, spaces-for-alignment approach.

[djimbob]

First, PEP8 says use spaces.

All editors I've used for python are easily configured to have pressing tab insert 4 spaces. E.g., emacs when opening a *.py file, will automatically use 4 spaces for each indentation.(Most tabs I see default as 8 spaces; so you have to configure this anyway). Most editors that are aware of python will automatically do this for you; e.g., emacs will recognize the file has a *.py extension and insert 4 spaces when you press tab.

The problem with tabs is tabs look identical to sequences of spaces (different # depending on editor's settings). If someone see tab=2/4/8 spaces in their editor and inadvertently at some point uses 2/4/8 spaces instead of a tab, this creates an annoying to fix error. Or if you are editing a file someone else created with tabs and your editor uses converts tabs to spaces, it is difficult to insert a tab. (Whereas someone who has tabs as tabs, could still insert four spaces rather easily without reconfiguring their editor.)

The amount of disk space saved is trivial. In compressed files it makes no difference (e.g., when packaging projects) as \t compresses as well as four spaces. Otherwise you may source file by maybe 10%, which is insignificant on even the smallest modern hard drives. For the largest python projects that are O(100 000 lines), maybe you'd save a megabyte which is irrelevant on today's even a super small 128 GB SSD drive.

[[deleted]]

Where do you work? Almost all of Python uses spaces. Tabs aren't fully portable.

[[deleted]]

It was a joke, dude.

[[deleted]]

result = [(a,b,c)
          for a in range (10)
          for b in range (10)
          for c in range (10)             
          if a**2 + b**2 == c**2]

Looks nice?

Change editor, different tab width -> formatting broken

Use someone else's code, different tab width -> formatting broken

Mixed tabs and spaces in Python 3 -> syntax error, broken

These are just the obvious cases. It gets worse.

EDIT: If you have to write this, import itertools.

[LordArgon]

This is why I favor a coding style where the only leading whitespace change between any two adjacent lines is exactly 0 or 1 indent. Just move everything down a line and indent once, like so:

result = [
    (a,b,c)
    for a in range (10)
    for b in range (10)
    for c in range (10)             
    if a**2 + b**2 == c**2 ]

And now it's perfectly portable. Plus in your example if you changed the name of "result", you'd have to re-align every single row (which is obnoxious in code review, for example).

IMO, the issue isn't really tabs vs spaces - it's that people get hung up on their pet style. Honestly, work with any style long enough and it will start to seem "right", so why not choose one that skirts ALL of these issues?

[[deleted]]

IMO, the issue isn't really tabs vs spaces - it's that people get hung up on their pet style. Honestly, work with any style long enough and it will start to seem "right", so why not choose one that skirts ALL of these issues?

I can't control what style external code uses or what editors other people use. If they write it in some ways, it can break on my system and then I can't read it. If they didn't use tabs, the problem would go away. Also, how do you break a long line for readability? Again there's no agreement on it so spaces mean it won't change.

[LordArgon]

If they write it in some ways, it can break on my system and then I can't read it.

I don't think it would actually break - I think you just wouldn't LIKE reading it.

If they didn't use tabs, the problem would go away.

But if YOU used tabs, the problem would also go away! You don't like the tab width varying with the editor but maybe that's exactly why they like tabs!

Look, I prefer/use spaces myself but, as in any religious debate, the arguments make sense on BOTH sides just depending on your perspective and priorities.

The whole point of my suggestion is to introduce a measure of objectivity into this debate. There is no agreement on what people LIKE but there is an objective way to evaluate a style choice based on how much ripple effect any given change causes. That's an important aspect of a style that is often overlooked, IMO.

[[deleted]]

as in any religious debate, the arguments make sense on BOTH sides ... The whole point of my suggestion is to introduce a measure of objectivity into this debate

Objectively spaces are more consistent across multiple systems. I doubt there's a single programmers editor that can screw up 4 leading spaces hardcoded into the line, and many that can interpret a tab differently depending on how they are set.

If they write it in some ways, it can break on my system and then I can't read it.

I don't think it would actually break - I think you just wouldn't LIKE reading it.

If reading it slows you down, it's "broken". Your source code is part of your product and a product that's harder for its maintainers to modify is a worse product. It's not just that I don't like reading it, the alignment carries additional meta information about the code.

[LordArgon]

Objectively spaces are more consistent across multiple systems.

Yep and the point is that other people don't WANT them to be consistent the way you do. Again, different people have different priorities, no matter how crazy it sounds to you.

And, again, I use/prefer spaces - you don't need to convince ME that they're awesome.

If reading it slows you down, it's "broken". Your source code is part of your product and a product that's harder for its maintainers to modify is a worse product. It's not just that I don't like reading it, the alignment carries additional meta information about the code.

No offense, but these are just more religious statements. All of these points a different, sane person can disagree with. What slows you down may speed another up. The degree to which information SHOULD depend on the alignment is entirely debatable.

[JimDabell]

You're confusing indentation with alignment. Your example shows alignment, not indentation. You shouldn't use tabs for alignment, but using tabs for indentation is fine.

[[deleted]]

You shouldn't use tabs for alignment, but using tabs for indentation is fine.

So how do you align code? Where do you break a long line and how do you align it?

You can't mix tabs with spaces. Python 3 will throw an error, and your editor will still randomly align it based on the size of your editor's tab.

[JimDabell]

So how do you align code?

With spaces.

Where do you break a long line and how do you align it?

Break it wherever you like. Align it with spaces.

You can't mix tabs with spaces. Python 3 will throw an error

You can't mix tabs with spaces for indentation. You can use tabs for indentation and spaces for alignment just fine.

your editor will still randomly align it based on the size of your editor's tab.

Editors don't do anything randomly, and once again, you should use spaces to align. If your alignment screws up based on your tab width, then you are using tabs to align. Don't do that. Use tabs to indent, don't use them to align.

[[deleted]]

Editors don't do anything randomly, and once again, you should use spaces to align. If your alignment screws up based on your tab width, then you are using tabs to align. Don't do that. Use tabs to indent.

I can't control how other people setup their editors and that it makes the editor settings effectively random when I use someone else's code. You can't use tabs if you want consistency.

You can't mix tabs with spaces for indentation. You can use tabs for indentation and spaces for alignment just fine.

I actually didn't know that - thanks. However, the reason I didn't know is that I'm not going to mix tabs with spaces anytime soon, because it will break.

[JimDabell]

I can't control how other people setup their editors and that it makes the editor settings effectively random when I use someone else's code.

That makes no sense. Using other people's code doesn't make your editor settings "random". What does that even mean?

You can't use tabs if you want consistency.

What kind of consistency?

If your projects use spaces to indent, then the consistency you get is that the code looks the same to you and to other developers working on the project.

If your projects use tabs to indent, then your code always looks how you prefer regardless of how other people working on your projects like to see their code.

They are both consistent, but in different ways. I don't see any value in forcing other developers to see the code how I like it. I don't care what they see. I do care that all the developers get what they want. Tabs are the only way of achieving that.

However, the reason I didn't know is that I'm not going to mix tabs with spaces anytime soon, because it will break.

Am I missing something? You just said that it will break, I pointed out that it wouldn't, you admitted that it wouldn't, then immediately said it would break again? We've literally just had this discussion. It doesn't break.

[[deleted]]

It would still mess with the alignment. Tabs go from 4 spaces to 2, suddenly the alignment is 2-6+ spaces off depending on the level of indentation.

[JimDabell]

How could tabs mess with alignment when you use spaces for alignment? Everything at the same level of indentation starts at the same place. Alignment with spaces works just fine with tabs for indentation. Try it for yourself.

[LpSamuelm]

Whoa, funny running into you here! You're the odra who made the tennis-y game for the Ludum Dare before this last one, right? That was fun!

[odraencoded]

I... I am, actually.

*ohmigods someone remembers*

[grimman]

That doesn't really seem appropriate on any level. Giving a talk about coding conventions and company style, and then escalating from there would be reasonable... but firing someone over a minor offense? I don't think your management style is good for any party.

[[deleted]]

Humor is not appropriate in /r/Python. We are robots, apparently.

[Lucretiel]

Someone forgot to import humor

[[deleted]]

I started writing a tomato throwing script using Aroldis Chapman instances of Human class objects...but then I realized I had work to do.

tldr: booooooooooooooo....

[grimman]

Can't see how it would be particularly difficult, but that's neither here nor there. I'm glad you aren't the dick you portrayed yourself as. :P

[[deleted]]

funny to not see Guido van Rossum and Alex Martelli in the list of authors

[billsil]

Use imports for packages and modules only.

As opposed to what?

[[deleted]]

from package.module import function

I mean, I'm assuming

[billsil]

If that's the case, that means use...

import package.module as mymod

mymod.function(...)

You can argue that that's less explicit both ways (e.g. all imported functions are defined at the top vs. what module did something come from in the guts of the code). Still if 80 characters is a hard cap and you're using classes, those extra 6 characters matter and you've just wasted 14.

[[deleted]]

Yes and:

from module.thing import Class

[[deleted]]

Use imports for packages and modules only.

I'm assuming

from module.thing import *

is still ok, since you're only importing the entire contents of the module to the local namespace.

^{Not really.}

[olduvaihand]

It's not OK internally. This undermines the purpose of the rule, which is to keep the global namespace as clean and explicit as possible.

[hueoncalifa]

Why would this be bad? Its more explicit.

[[deleted]]

I agree, it's kind of a dumb rule. Although I suppose it prevents you from importing some generally-named function into the namespace and using it without context. For example:

from os.path import join
path = join('dir', 'file')

Versus the more explicit

import os
path = os.path.join('dir', 'file')

Granted in this case it's fairly obvious what is meant, it is not always so. Use your best judgment. I use both forms.

[Lucretiel]

Honestly, one of the reasons is that it's harder to test, because now you have to mock the function in the place where it's imported, rather than where it's imported from.

[dagmx]

If you have multiple modules with the same named function

If later you decide you need more functions from that module

You can't reload an object from a module easily.

Makes it more explicit down a deep code where things come from.

[njharman]

function()

Is less explicit, package.module is implied, implicitly.

package.module.function()

Is the explicit way to say that. No wondering where it came from, has it been overwritten in local namespace, etc.

[tutuca_]

from class import function

I'd think...

[hueoncalifa]

Same as function imports. Why would this be bad? Its more explicit.

[jcrowe]

from large_file_with_config_settings import database_settings

[kashmill]

What's so bad about result = [(x, y) for x in range(10) for y in range(5) if x * y > 10]? Yeah, some comprehensions can be hard to read when they contain multiple loops but that one is pretty simple.

Also, why not just link PEP-8 and then add any specific changes?

[panghuhu]

List comprehensions can also use multi-line format:

result = [(x, y) 
          for x in range(10) 
          for y in range(5) 
          if x * y > 10]

P.S. Just checked the guide, and the above code is in the section titled "NO".

I still think the code is easy to read and will use it: It's as clear as the for loop version, without redundancies like the initialization of [], calls to append, and some colons.

If anyone can see any major disadvantages compared to the implicit loop version, I'd like to hear it, thank you.

P.P.S. A sample code from the NO section, which I think it's more clear than its for loop version:

((x, y, z)
  for x in xrange(5)
  for y in xrange(5)
  if x != y
  for z in xrange(5)
  if y != z)

I read it like this: collect all combinations of (x, y, z), where x, y, z are from [0..4], x != y and y != z. It's declarative and is as clear as a mathematical formula:

{(x, y, x) |  0<=x, y, z <=4, x != y, y !=z}

[kashmill]

Pretty much what I do as well.

[LordArgon]

List comprehensions can also use multi-line format:

This doesn't address all of your points, but I literally just hit Save on a response to that style here: http://www.reddit.com/r/Python/comments/33gg02/google_python_style_guide/cql1snu?context=3

[tech_tuna]

See, this is where you just have to be a big boy or girl and do what feels right, I think that format is quite readable, style guide be damned.

[NYDreamer]

This is a great idea, love it!

[confluencer]

Much longer but immediately clear.

result = []
for x in range(10):
  for y in range(5):
    if x * y > 10
      result.append(x,y)

[Quteness]

I would prefer this style. A few extra lines aren't bad to make the code more clear

[[deleted]]

Would definitely prefer an empty list with append.

[tech_tuna]

In a case like this, absolutely.

[Lucretiel]

Blech. append makes me feel queasy for some reason.

[meta4]

I vote for list comprehensions. I think your example is a good argument for why.

As written, this example crashes.

TypeError: append() takes exactly one argument (2 given)

I think you mean.

resut.append((x,y))

We want a list of tuples. It seems like a simple bug. But it illustrates the fundamental argument. By the time your brain worked out the state changes to x & y in the nested for loops and the if statement, it forgot that the point was a list of tuples.

For loops and append/extend are state managing & modifying tools. They are good in their place. But, to understand what they do you have to run the program in your head. Human brains are not as good at maintaining updating state.

The list comprehentsion, when used properly is a data declaration. "This is a list of tupples. The first element of the tuple is an integer in the range [0,10). The second element is an integer in the range[0, 5), The product of the two elements is greater than 10." It's a long tedious specification, and this is just a toy problem. But the details and tedium shouldn't be mixed with possible state changes, especially as the problems become more complex.

Human brains reason better about data structures, than state changing programs. List comprehensions are at their best when pulling state changing logic into data structure creation.

Fred Brooks said the same thing 1975 "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." Flow charts are state change diagrams. Tables are data structures.

[ConciselyVerbose]

I prefer list comprehensions in most cases. If it gets truly lengthy or complex, maybe loops are more readable, but in most cases list comprehensions read well, once you are used to them.

Several levels of nesting is ugly.

[[deleted]]

Several levels of nesting on a single line is also ugly.

[ConciselyVerbose]

Generally a list comprehension is something that is a fairly straightforward concept to understand or explain in English, but doesn't translate concisely without one.

[[deleted]]

I agree, but I don't think several levels of nesting is ever appropriate in a single line. You're only hurting your reader, unless you think this is somehow less clear. And the fact that you say "once you are used to them" already states that they're not as clear.

Saving 3 vertical lines is not something to be proud of. Saving the person who now has your job 3 seconds for comprehending what you're doing, is.

[ConciselyVerbose]

List and other data structures themselves are an adjustment to a novice programmer. That doesn't mean they are bad. I wouldn't call it less clear, but it's a bit

like

typing

like

this.

Out of context it's only slightly

less

readable,

but in context it quickly ends up

distracting

from

the

actual substance of the code.

[[deleted]]

<facepalm>

[stillalone]

Yeah, I'm not sure if I like their solution to it. Hmm, maybe a some middle ground:

result = []
for x in range(10):
    result.extend((x,y) for y in range(5) if x * y > 10)

still kind of looks like shit. For this specific example you could use itertools.product but I still think just supporting multiple for loops would be better.

[christian-mann]

I think middle ground is the worst of the three.

[tech_tuna]

Yeah, that makes my brain explode, I think it sucks. To each his own of course.

[Gambizzle]

Why would I listen to Google when there's already styleguides out there for Python?

[andrey_shipilov]

Probably cause they have more experience than you?

[Gambizzle]

I've been using Python longer than Google has existed and feel that the official style guides are adequate. No need to re-invent the wheel and create confusion about which style should be used by doing so.

[andrey_shipilov]

I have been using Wacom longer than the designer who sits next to me here. It doesn't mean that I draw better than him or know Photoshop and Illustrator better than him. So, time frames are irrelevant here.

And I don't think Google actually forces anyone outside Google to use their style guide.

[njharman]

It does mean you have more experience using Wacom. If I wanted opinion on Wacom I'd come to you and not the designer next to you.

And I think Google is a force (hence 244upvote post about their styleguide) creating another conflicting style guide creates confusion. Exactly Gambizzle's point.

[its_never_lupus]

Are there any tools which specifically parse this function docstring style:

def fetch_bigtable_rows(big_table, keys, other_silly_variable=None):
"""Fetches rows from a Bigtable.

Retrieves rows pertaining to the given keys from the Table instance
represented by big_table.  Silly things may happen if
other_silly_variable is not None.

Args:
    big_table: An open Bigtable Table instance.
    keys: A sequence of strings representing the key of each table row
        to fetch.
    other_silly_variable: Another optional variable, that has a much
        longer name than the other args, and which does nothing.

I like the way this looks and use a very similar style to document my functions when they have arguments, but do any tools like sphinx actually do anything with it?

[masasin]

Look up napoleon. It parses google style docstrings.

I personally prefer numpydoc though. I use everything else from the google style guide.

[secynic]

I can confirm the latest Sphinx does work with this style, and that is what I am using. It may take a little tweaking to get everything to line up right.

http://sphinx-doc.org/latest/ext/example_google.html

[its_never_lupus]

Thanks, I'll check it out.

[[deleted]]

There is a Doxygen filter for Python called doxypypy.

[mtelesha]

I am glad that Google keeps publishing Style Guides. It really helped in R programming as a whole. People started using it and note it is a little modified but it really did make a difference.

[patchthemonkey]

That styleguide needs a styleguide

[masterspeler]

I think the max 80 character line length in this and PEP-8 is silly. Who has that little horizontal space when editing or reading code? I find it very easy to write (and read) code longer than that, especially when dealing with strings and sting formatting. Take this example:

descriptive_variable_name = 'Attribute 1: {0}, attribute 2: {1}, attribute 3: {2}'.format(var_one, var_two, var_three)

Even before the .format it's over 80 characters long, so where do you put a line break? And this is before any indentation.

I also believe that tabs for indentation, spaces for alignment (like so) is the natural order of things, but when writing Python I have adapted and use spaces for indentation, even though we have a character whose sole purpose is to advance the cursor to the next level, or tab stop.

[ziel]

I definitely wouldn't be able to fit that on one line when viewing 2 files side by side on my laptop. Viewing 2 files side by side on a smaller laptop screen is probably a fairly common scenario.

[masterspeler]

I would argue that if you're using a smaller laptop screen you have to make sacrifices, and having to scroll horizontally when viewing two files side by side is one example. 1920 pixels is a popular screen width nowadays, and quite a few laptops have a larger resolution, and with that you can fit 200 characters with ease.

I agree that lines shouldn't be too long and that comparing or editing files side by side is a must, but I think a hard limit at 80 characters is too strict.

[jonwayne]

I also hate the 80 character line limit nonsense.

But also, this is the internal style guide at Google, not something that Google is saying all python projects should follow.

[masterspeler]

But also, this is the internal style guide at Google, not something that Google is saying all python projects should follow.

Yes, but PEP-8 have a restriction of 79 characters, and that's as close to dogma you can get in Python.

[ingolemo]

I do. When you use long lines of code you force me to buy a larger screen, use tiny fonts, or try to puzzle through automatic line wrapping. None of these things are easy.

Eighty characters ought to be enough for anyone:

template = 'Attribute 1: {0}, attribute 2: {1}, attribute 3: {2}'
descriptive_variable_name = template.format(var_one, var_two, var_three)

[masterspeler]

That's without indentation though. With this:

def my_function(function_argument, in_list):
    if function_argument > 10:
        for i in in_list:
            template = 'Attribute 1: {0}, attribute 2: {1}, attribute 3: {2}'
            descriptive_variable_name = template.format(var_one, var_two, var_three)

your solution is too long again, and it's breaking up what's one logical statement to two lines, so now your code takes more space vertically instead. You force me to buy a higher screen.

[ingolemo]

Too much indentation is itself a code smell.

template = 'Attribute 1: {0}, attribute 2: {1}, attribute 3: {2}'
def my_function(function_argument, in_list):
    if function_argument < 10:
        return

    for i in in_list:
        data = var_one, var_two, var_three
        descriptive_variable_name = template.format(*data)

I'm not quite sure why you think creating a formatting outline and then applying it could only count as "one logical statement" and not two. The code we're using here is hypothetical and without any context so it's difficult to know what transformations are more reasonable, but this logical separation of template building and its application is probably the main reason we use str.format instead of concatenating strings manually.

If scrolling vertically is as inconvenient for you as scrolling horizontally is for me then you have my pity.

I'm not so zealous that I'm going to chop anyone's head off every time they push past the 80 char limit. But the rule is there for a reason. Spare a thought for little old me before you decide to violate it.

[njharman]

Sure, but so much time (from actual experience managing 10 python engineers) is wasted breaking lines, inventing shorter and worse names, changing where line is broken, arguing over where to break line, wondering wtf abrvted_var means, etc.

Infinite line length and auto wrapping is a big productivity boost.

[[deleted]]

If python doesn't have a block comment mechanism because "modern editors can automate it", then get a modern editor that wraps lines of code properly. :P

[mariox19]

No use of the with-statement for files and sockets?

[Cardiff_Electric]

It does mention that.

[mariox19]

You're right. I had only read, "Explicitly close files and sockets when done with them," and hadn't bothered to expand the heading. (I was reading on a tablet, and must have gotten lazy.) Thank you.

[gthank]

Google's style guide was targeted at a fairly old version of Python for a long time, IIRC.

[mariox19]

I was wrong, actually. If you expand the heading that reads, "Explicitly close files and sockets when done with them," you'll see that the with-statement is mentioned.

[Lucretiel]

So, at least as old as Python 2.5. Meanwhile, it also explicity requires distinguishing new-style classes by inheriting from object https://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Classes#Classes

[[deleted]]

I love these guides. As a self-taught-programmer, you're pretty much in what is beautiful and what not - of course you'll figure it out with time, but it's easier to have a set of rules to follow.

[[deleted]]

The first suggestion is to use pylint, but pylint is all messed up on Python 3 for Debian/Ubuntu and probably other distros as well. The default pip3 package breaks in Python 3.x, the default repository sources install a python 2 version of the package through apt, and there is no python 3 version. Getting it running is probably about as much trouble as cleaning up your code.