Python gets a "Developer-in-Residence"

Posted Jul 29, 2021 10:05 UTC (Thu) by rsidd (subscriber, #2582)
In reply to: Python gets a "Developer-in-Residence" by hynek
Parent article: Python gets a "Developer-in-Residence"

Thanks. I hadn't encountered Black before, but on reading the docs, it certainly looks like any version differences are minor and shouldn't restyle everything (if already restyled by a previous version of Black). But it does sound like you should use only Black and not mix it with any other styler. So the shouty comment does sound like FUD. The author probably had a genuine bad experience, but there are more productive ways to share it.

Python gets a "Developer-in-Residence"

Posted Jul 29, 2021 12:28 UTC (Thu) by hynek (subscriber, #55397) [Link] (5 responses)

Yes, since Black formats everything to a canonical shape, it makes no sense to have other formatters.

With one exception: isort, because Black doesn’t format imports.

Python gets a "Developer-in-Residence"

Posted Jul 29, 2021 19:14 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (2 responses)

> With one exception: isort, because Black doesn’t format imports.

AIUI, this is a deliberate choice on the part of Black, because imports can have side effects.

(Imports *should not* have side effects. You should be able to reorder them without breaking anything. But bad code exists, so...)

Python gets a "Developer-in-Residence"

Posted Jul 30, 2021 7:37 UTC (Fri) by hynek (subscriber, #55397) [Link] (1 responses)

It's even more complicated than that.

Since PEP 8 asks you to sort your import into blocks of standard library, 3rd party packages, and app packages, a non-trivial insight into the packaging situation of the current app/package is required. Thus it makes sense to punt on it, since it would open a completely new can of worms and the code is already present in isort.

Python gets a "Developer-in-Residence"

Posted Jul 31, 2021 21:57 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

Right. But Black's documentation also says that it is not supposed to change the AST at all, except in a small number of special cases which should not affect runtime behavior.[1] Since import-reordering actually could change the runtime behavior, I think they consider it permanently out-of-scope, rather than just "too hard."

(As mentioned before, there is no good reason for import-reordering to change runtime behavior. It's just that Python doesn't have any hard limits which prevent you from shooting yourself in the foot like that.)

[1]: https://black.readthedocs.io/en/stable/the_black_code_sty...

Python gets a "Developer-in-Residence"

Posted Jul 30, 2021 8:22 UTC (Fri) by rsidd (subscriber, #2582) [Link] (1 responses)

If I understand the Black docs right, Black formats imports (I just checked: it does), but doesn't sort them?

Python gets a "Developer-in-Residence"

Posted Jul 30, 2021 14:01 UTC (Fri) by kpfleming (subscriber, #23250) [Link]

Correct. (plus some characters)

Python gets a "Developer-in-Residence"

Posted Jul 31, 2021 7:43 UTC (Sat) by LtWorf (subscriber, #124958) [Link] (2 responses)

> So the shouty comment does sound like FUD. The author probably had a genuine bad experience, but there are more productive ways to share it.

It's not FUD if it's real.

It's a tool that in theory wants to be like go fmt, but in practice isn't, and creates the need to reformat the whole codebase (and pollute commit history) periodically.

Python gets a "Developer-in-Residence"

Posted Jul 31, 2021 10:53 UTC (Sat) by rsidd (subscriber, #2582) [Link] (1 responses)

It aims to minimize diffs. The version-to-version changes suggest that some small specific bits, at most, would be reformatted, so the diff from formatting a previously Black-formatted file with a new Black version should be tiny.

If you really have an example where the entire file was changed by a new version of Black, why not report that as a bug? I don't see how that can happen with any format tool, actually.

Python gets a "Developer-in-Residence"

Posted Jul 31, 2021 13:42 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> I don't see how that can happen with any format tool, actually.

The usual culprits in my experience include (in a rough order):

- line length breaking heuristics
- updates to the language (e.g., C++03 → C++11 made lots of "> >" → ">>" diff noise)
- more insight into comments (reflowing paragraphs or such) or macros