pylama VS black

Pylama is a code audit tool for Python that wraps tools like Pylint, pycodestyle, PyFlakes, McCabe, and others to provide a unified interface.

Use a code linter. And potentially use black.

Use a linter like pylama

Lint your code. I recommend pylama.

Linters analyze code to detect various categories of issues like logistical issue and stylistic issues. Some popular linters are Pylint, pycodestyle, Flake8 and Pylama.

👉 https://github.com/psf/black

Coming from a Meta background (not speaking on behalf of Meta):

"package/dependency management" - Everything is checked into a monorepo, and built with [Buck2](https://buck2.build/). There's tooling to import/update packages, but no need to reinvent pip or other package managers. Btw, Buck2 is pretty awesome and supports a ton of languages beyond python, but hasn't gotten a ton of traction outside of Meta.

"linting, formatting" - [Black](https://github.com/psf/black) and other public ecosystem tooling is great, no need to develop internally.

"why is type checking the exception" - Don't know about Astral, but for Meta / Google, most everyone else doesn't design for the scale of their monorepos. Meta moved from SVN to Git to Mercurial, then forked Mercurial into [Sapling](https://sapling-scm.com/) because simple operations were too slow for the number of files in their repo, and how frequently they receive diffs.

There are obvious safety benefits to type checking, but with how much Python code Meta has, mypy is not an option - it would take far too much time / memory to provide any value.

These requirements are not too uncommon. I have seen many projects with similar setup, with alternatives such as tox instead of nox, or black and pylint instead of ruff, etc.

Use black and isort for formatting.

black as a formatter,

repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.4.0 # Use the desired revision hooks: - id: trailing-whitespace - id: end-of-file-fixer - repo: https://github.com/psf/black rev: 23.1.0 # Use the appropriate version for your project hooks: - id: black - repo: https://github.com/pycqa/flake8 rev: 6.0.0 hooks: - id: flake8

> I appreciate that Black annoyed everyone on our team about the same amount but in different ways.

If it did affect people equally, it would be great. Unfortunately, spaces for indentation is an accessibility issue and the Black maintainers are hostile to making this configurable. Normally I am in agreement about minimising configurability, but this isn’t a matter of taste, it is making the Python ecosystem more difficult for some disabled people to participate in.

https://github.com/psf/black/issues/2798

Fortunately, Ruff makes this configurable, so you don’t have to choose between autoformatting and accessibility any more.

XO. This feels like the Black of Typescript linting. XO has styles for everything and is very opinionated. This can be nice, because it takes a lot of code style decisions off of your plate. But beware it can be cumbersome to implement in the middle of a project because it will require extensive reformatting. In lieu of XO, I found Unicorn opinionated enough and more immediately useful.

Black (Python Code Formatter) - Black is a widely used opinionated Python code formatter that helps standardize the look of Python code. Its primary advantage is that it eliminates arguments over style, helping teams stay productive.