How many spaces to indent Python code?

[Daniel Cheng]

The Google (Chrome?) style guide says to indent 4 spaces (I think it previously used to be 2).

In depot_tools, it seems that some files use 4 space indents, while other files use 2 space indents. However, .yapf.conf specifies a 2 space indent, and that makes it rather annoying to work on files with a 4 space indent: the presubmit wants to reformat (basically) the entire file.

Any thoughts on how to resolve this?

Daniel

[K. Moon]

The Google Python style guide has been slowly trying to converge (as much as possible) with PEP8 over time, which is probably where the 2-to-4 switch came from.

I suspect the best resolution would be to reindent everything.

The current style guide assumes use of Black or PyInk, rather than YAPF. Those formatters tend to be more opinionated, so I'm not sure if they would change less than YAPF does (which further reinforces my suspicion that reformatting is the way to go here).

--
You received this message because you are subscribed to the Google Groups "python" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python+un...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/python/CAF3XrKqNnotGBJY4QE4ELwvSNYf%3DBYWfjQip0a6KQqHoP_2bFw%40mail.gmail.com.

[Dirk Pranke]

The Chromium Python style guide  says to follow PEP-8. I.e., 4-space indents. The (non-Chromium) Google style guide basically follows that.

However, there is also this section, which explains that we used to use 2-space indents, and that you should use 4-space indents for new code and 2-space in old code if that's what the rest of the file uses.

I don't know if there's a way to get YAPF or Black to follow that, but it's bad if our presubmit checks are explicitly trying to require 2-space indents. I'd probably vote for turning off the formatter instead if we can't get it to do what we want, but I'm curious if others have other opinions?

-- Dirk

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/python/CACwGi-4Ue35hUAswsPOH7q3-D3NE9N45H0Lr6byeyiVch4E-rg%40mail.gmail.com.

[Alexei Svitkine]

FYI: The internal Google Py style guide still says to indent 2 spaces:

go/pystyle#indentation

Just speaking from the point of view of my team (Chrome Metrics), we do a lot of development internally following the above style and some of our Chromium source mirrors our internal versions. So introducing a formatting difference would add an additional burden in keeping logic in sync.

We could theoretically try to refactor things such that any "shared" logic/code is imported into Chromium via third_party or imported from Chromium to the internal codebase also through the third party mechanism, but this would require quite a bit of work due to how the code is structured right now and the fact that there's some divergences in logic due to additional requirements internally that don't exist in Chromium, etc - so we'd need to add extension points to the APIs, etc. And while perhaps such an effort could reach a good solution, it's not currently really the priority for us since we'd rather be working on other things.

So for us, the status quo is currently preferable (where some directories in Chromium follow the 2-space indent per the internal Google Py style guide).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/python/CAEoffTAjgPvX3CmsXpvy8DCMpCSDk7W%2B1jTc00-97Xefw-2AXQ%40mail.gmail.com.

[Mike Frysinger]

we should blank reformat depot_tools at this point

-mike

--

[Daniel Cheng]

Looking a bit more closely, depot tools currently appears to largely use a 2 space indent.

TBH I don't feel too strongly about this, except:

- I'm editing a file which uses a 4 space indent for the first level of indenting, and then 2 spaces for the rest (!!)

- git cl upload complained that the formatting was incorrect

- I reformatted everything per git cl format

- The reviewer pushed back against git cl format changing everything to a 2 space indent, because pyt...@chromium.org had pushed back on this strongly in the past

Unfortunately, I don't think there's a way to change .yapf.conf to use the "majority indenting" in a file—or if there is, I can't find it. If I go with 4 space indents, I have to ignore the presubmit checks complaining about misformatted code.

But I would like to land my change, and so I would like a definitive opinion on which way to go for depot tools :)

Daniel

[Mike Frysinger]

https://crrev.com/c/4836379

-mike

[Dirk Pranke]

I actually thought Google-internal style had switched to the same rules as us (4 spaces for new code), but I guess not.

I was gonna say that I'd do 2-space in depot_tools, but I guess we can see what they'll do with Mike's change.

4+2 is definitely wrong ;).

-- Dirk

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/python/CAAbOSc%3DGVqjmW2_d%3Df64FyXyDkKmdDHDhwi%2BLAoj5FGVut02sw%40mail.gmail.com.

[Nico Weber]

If `git cl format` produces 2 space indent, check if some parent dir has a .style.yapf file with `indent_width=2`. In that case, consider adding a .style.yapf in your dir that doesn't have that.

(This just bit me in a subdir of src/tools.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/python/CAF3XrKqPTQFdyRNGGLp%2Bu4A%2B1KEdp3p%3D%2BDxH7h3DL809%3DS10YA%40mail.gmail.com.

[Mike Frysinger]

my CLs to reformat depot_tools to 4 space with yapf have landed. some of it wasn't pretty (notably docstrings), but hopefully the rest should be ok.

I was running yapf directly. I assume git cl format works even though I didn't run it directly because, afaik, git cl upload runs that for you as part of preupload checks.

-mike