Chromium Python Style Guide

For other languages, please see the Chromium style guides.

As of 2021-05-12, Chromium is transitioning from Python 2 to Python 3 (follow crbug.com/941669 for updates). See //docs/python3_migration.md for more on how to migrate code.

For new (Python 3) code, you can assume Python 3.8 (and that's what the bots will use), but we are increasingly seeing people running 3.9 locally as well.

We (often) use a tool called vpython to manage Python packages; vpython is a wrapper around virtualenv. However, it is not safe to use vpython regardless of context, as it can have performance issues. All tests are run under vpython, so it is safe there, but you should not use vpython during PRESUBMIT checks, gclient runhooks, or during the build unless a //build/OWNER has told you that it is okay to do so.

Also, there is some performance overhead to using vpython, so prefer not to use vpython unless you need it (to pick up packages not available in the source tree).

“shebang lines” (the first line of many unix scripts, like #!/bin/sh) aren‘t as useful as you might think in Chromium, because most of our python invocations come from other tools like Ninja or the swarming infrastructure, and they also don’t work on Windows. So, don't expect them to help you.

However, if your script is executable, you should still use one, and for Python you should use #!/usr/bin/env python3 or #!/usr/bin/env vpython3 in order to pick up the right version of Python from your $PATH rather than assuming you want the version in /usr/bin; this allows you to pick up the versions we endorse from depot_tools.

Chromium follows PEP-8.

It is also encouraged to follow advice from Google's Python Style Guide, which is a superset of PEP-8.

See also:

Our Previous Python Style

Chromium used to differ from PEP-8 in the following ways:

  • Use two-space indentation instead of four-space indentation.
  • Use CamelCase() method and function names instead of unix_hacker_style() names.
  • 80 character line limits rather than 79.

New scripts should not follow these deviations, but they should be followed when making changes to files that follow them.

Making Style Guide Changes

You can propose changes to this style guide by sending an email to [email protected]. Ideally, the list will arrive at some consensus and you can request review for a change to this file. If there's no consensus, //styleguide/python/OWNERS get to decide.

Tools

pylint

Depot tools contains a local copy of pylint, appropriately configured.

  • Directories need to opt into pylint presubmit checks via: input_api.canned_checks.RunPylint().

YAPF

YAPF is the Python formatter used by:

git cl format --python

Directories can opt into enforcing auto-formatting by adding a .style.yapf file with the following contents:

[style]
based_on_style = pep8

Entire files can be formatted (rather than just touched lines) via:

git cl format --python --full

YAPF has gotchas. You should review its changes before submitting. Notably:

  • It does not re-wrap comments.
  • It won't insert characters in order wrap lines. You might need to add ()s yourself in order to have to wrap long lines for you.
  • It formats lists differently depending on whether or not they end with a trailing comma.

Bugs

Editor Integration

See: https://github.com/google/yapf/tree/main/plugins