not (x in y) -> x not in y; not (x is y) -> x is not y

[JelleZijlstra]

This is a feature idea; feel free to declare it out of scope. Replace not (x in y) with x not in y and not (x is y) with x is not y.

[ambv]

I agree with the premise but that wouldn't be compatible with --safe. Once --safe is no longer the default (that's when Black goes stable = way later in the year), we can introduce those sorts of transformations.

[ambv]

If you're willing to work on this, @JelleZijlstra, then it will go in. Otherwise we'll mark out of scope.

[merwok]

One could argue that this is a matter of programming style, not aesthetic style, and that black’s domain is the latter only (I could be wrong).

Black’s goal is to remove the tedious explanations and arguments over aesthetics in code review, but there are other parts to a coding style guide / best practices defined by a company or group, and other tools can warn / change things that black doesn’t touch.

[Zac-HD]

pybetter or shed --refactor do this, for what it's worth - see https://github.com/life4/awesome-python-code-formatters.

[felix-hilden]

I'd interpret Łukasz's comment to mean that --safe and --fast will eventually do different things, not just toggle the safety check. Maybe he meant that --safe would fail in this case, but I think disabling the relevant transforms would be better. This also relates to the AST changes discussion in #2150.

I know this is an old issue, but for my two cents I'd say that the change Jelle proposed sounds good, and so does the idea that --safe (or some other similar flag) will disable all formatting that changes AST. That would allow us to go further into formatting opinions, like docstrings for example.

[JelleZijlstra]

I'd interpret Łukasz's comment to mean that --safe and --fast will eventually do different things, not just toggle the safety check.

I don't know what Łukasz meant but I'd be opposed to that. --safe and --fast are orthogonal to formatting choices and shouldn't affect what formatting we do.

We could implement the suggestion from this issue and put a custom condition in the AST comparison logic that allows it, like we already do for a few other cases.