Revert “Black by default”

Version 8.0 added automatic formatting with Black. This was added in #13397 without much discussion - at least there is none linked.

IMO this is not desirable. It is surprising for a REPL to change what you wrote, and it introduces a large dependency (Black). As @rhettinger has pointed out on Twitter it reduces the utility of IPython in educational contexts: https://twitter.com/raymondh/status/1482225220475883522

Additionally the release note read:

If black is installed in the same environment as IPython…

But this is misleading, implying that it’s opt-in by installing Black. The change made IPython depend on Black, so it is always be installed.

[Carreau]

The way Raymond Hettinger complained on Twitter is personally deeply hurtful. I hope he did not meant it the way I read it.

I’m not going to reply to some comments (here or elsewhere), and may closing and locking all the issue and stop maintaining IPython for my own mental sanity for some time (expect some critical things). So apologies if this is not completely proofread and if words are ill-chosen, and does not get feedback for a while.

To all of those that have nice and constructive comments and discussion, thanks a lot for expressing your opinions and understanding the difficulty of maintaining a software. Also thank a lot for understanding that not everyone has the same needs and preferences, instead of assuming that your way of doing this is the best in the world.

So, the actions IPython maintainers can take now are as follows:

1. make it explicitly opt-in;

To this and similar suggestions, ‘black’ auto-formatting has been opt-in for 2 years (may 1st 2020, IPython 7.14).

I had thought it might be problematic, but in two years received almost no bug reports. I tried a few time to say I was considering making it default and only got positive feedback. So I did it, with extensive alpha, beta, and RC time to complain and ask for modifications.

So here is my challenge, if I don’t make it the default, no-one know about it. It’s astonishing that no-one found the bug @ehamiter described above in 2 years ! That alone would have definitely delayed the release, and at least I would have had tried to fix it.

I’ve also seen a number of new users misformating Python code and taking really bad habits in the Repl, including folks that did not even realise IPython terminal was multiline.

For many of those users black by default is much better. You get use to proper code formatting. So you learn to properly read python code. And it is much easier to deactivate something you don’t like than even figure out it something that may exists. For many users this benefits to, having this option be opt-in would make black auto formatting be part of the [unknown unknowns].(https://en.wikipedia.org/wiki/There_are_known_knowns). So I will never get feedback from these. This is in the same vein as “but you can configure vim to do so”.

1. make it much easier to opt out;

It’s really hard to make it much easier, there have been a long standing issue to have persistent config, but that’s far beyond the time and funds we have for that in IPython. We could borrow a nice configuration interface like ptpython for the UI if Someone want to take a shot at ti.

1. stop depending on Black by default.

(As black is beta I agree that this is a problem I did not foresaw and will likely be removing at least the dependency, though I don’t really like that either).

As many have pointed out, it’s expected for major release to receive feedback because few users try --pre, and other channel, and it’s ok I expect it. But I much prefer a reaction like:

https://twitter.com/jnuneziglesias/status/1478867554009452545

Black formatting by default is 🤢 though 😜 — made myself a todo to turn it off. 😂 Can yapf be configured in its place?

Which I’m more likely to help with (and did in a thread). Than spitting on maintainers, which is painful and counter productive.

I’ll try to restore some of my mental sanity. I was hoping to do a 8.1 around last Friday of January (release friday), we’ll see what I can get in there.

[FlaviovLeal]

I would like to counter argument that black should be kept as default.

I personally like the change. Even while prototyping, an code formatter can really help you keep your code clean and legible, and black is easily one of the most popular python code formatter. I would also argue that new users should come in contact with code formatters early on their learning journey, as writing readable code is just as important as writing functional ones.

By keeping the feature as default, you make it more likely that new users will find this feature. Most people will not thoughtfully read all documentation and optional before starting to use a product, and by keeping it as default it’s very easy to present the feature to new users. Keeping opt out as default is a good strategy for product rollout.

Those who end up disliking the feature should have a easy time disabling it. According to the docs, you can disable it inside the terminal, on the command line, on the profile files, on the default profile. There is just so many ways to do so, that should fit most needs.

Lastly I do think making it a optional dependency is a good idea, but it’s a bit of sidetracking: We can have black as default and black dependency as optional, just as we can revert black as default and keep black being a dependency. Those two are not interconnected.