Revert “Black by default”

[adamchainz]

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.

[adamchainz]

💯 understand that it's really hard to know what users will think of any open source decision until release. Highly grateful for all your work on IPython @Carreau and others.

[ThiefMaster]

Please revert this.

In [2]: 2**3 + 4**5 + 6*7*8

becoming

In [2]: 2 ** 3 + 4 ** 5 + 6 * 7 * 8
Out[2]: 1368

is just terrible. Sure, it's a contrived example, but I think my point is clearly visible there...

[ThiefMaster]

Also, I think black should not be a hard dependency of ipython - make it an optional [black] extra instead. And still disable it by default regardless of whether black is installed or not :)

Usecase: My project adds ipython as a (non-development) dependency because it includes a REPL for some management tasks (flask shell like, just with ipython since it's much nicer than the default Python REPL). However, the project does NOT use black, and by default there's no black installed in the environment (when doing a dev setup), because well.. the project doesn't use black to auto-format code.

But now ipython pulls in black as a dependency and I think some editors might even detect this and suggest black to auto-format code...

[adamchainz]

Please don't pile on with comments like "this is terrible", it's not productive. Just indicate support with a thumbs-up on the issue.

make it an optional [black] extra instead.

Yes, this is another path.

I think some editors might even detect this and suggest black to auto-format code...

This is very true.

[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.

[ThiefMaster]

I personally like the change

Why not make it opt-in?

keep your code clean

If you do one-off tasks (let's say perfoming some maintenance in your app's REPL where all your DB models etc are available), it literally doesn't matter.

I would also argue that new users should come in contact with code formatters early on their learning journey

But not those that rewrite their code automatically. It's common to highlight formatting issue, provide a shortcut to auto-format and maybe even do it on commit. But right when typing? No, that's just confusing. "why did my code just change to look completely different" etc.

Those who end up disliking the feature should have a easy time disabling it

Many people do not configure ipython, especially those who just use it a a simple REPL. Defaults should be as user-friendly (e.g. enabled syntax highlighting) and non-intrusive (no auto-formatting/rewriting of code) as possible.

[simonw]

I absolutely adore Black and use it in all of my projects, but I find Raymond's education argument and the 2**3 + 4**5 + 6*7*8 example provided above very convincing.

I'd love the ability to explicitly opt-in to Black formatting on a global or per-notebook basis, but turning it on by default doesn't feel right to me.

[machinebiologist]

Personally, 90% of the time when I'm using the CLI, it's to run a quick test. And, when I'm testing something, the exact input that I've given is the exact input that I want to test.

Black's great, but it's not what I want to see in a CLI unless I've specifically enabled it.

[ehamiter]

I love IPython, and use it every day, and wanted to add something to this conversation that I have noticed while testing out black integration in the past on my own projects.

Enabling black introduces inconsistencies with how the magic commands use the preceding optional % symbol, and may affect some user's current workflows (as well as confuse new users). For example, to see your history list, you'd type

%history

while leaving off the % works as well:

history

But if you wanted to list it with a numbered list, you pass in -n:

%history -n

...but if you leave the % off, black will reformat it from

history -n

to

history - n

which is no longer a valid magic command.

[ambv]

I had no say in the decision to include Black in IPython so I'm opining here as a user. I understand that any decision is ultimately in the hands of IPython maintainers, and respect their right to choose whatever they find works best for their project.

I think having an option to auto-format code in the CLI and Jupyter cells is terrific. That being said, it being the default is rallying people against auto-formatting so it's somewhat counterproductive to what we want to achieve.

Note that I don't necessarily agree with taking any change to Python, or third-party projects like in this case, hostage to some nebulous case of "educating new users". It's trivial to demonstrate semicolon usage and other changes which would be auto-formatted away. In fact, it would be also educational to inform users why those things are getting auto-formatted away. Semicolons and backslashes are pretty uncontroversially discouraged in user code, no?

I know that the biggest point of contention is standardizing double quotes. I don't want to reopen the single quotes discussion but the choice was made after evaluating both variants. Saying that "Python itself prefers single quotes" is anthropomorphicizing a piece of software. It's silly. Again, educating new users would be more complete with an explanation of the reasons why standardizing quotes is done and why one is better than the other.

But I digress. The more important issue is auto-formatting scientific math-heavy lines. There isn't much that can be magically done by a simple tool like Black here in a consistent manner. We are evaluating improvements in this area, specifically in the most often brought up case of hugging power operands. That being said, I don't think this will be an area where everybody will be happy whatever Black does.

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

1. make it explicitly opt-in;
2. make it much easier to opt out;
3. stop depending on Black by default.

My personal preference would be to definitely do 3. but also 2. Depending on Black brings a number of other dependencies to the venv which might not be in the versions people want. And opting out even if Black is importable shouldn't require me to bring up the docs for the magical incantation every time. It should be trivial to remember. (something like # fmt: off)

But, again, this is ultimately the maintainers' choice. I'm happy to help if you need anything.

[ThiefMaster]

Since you mentioned semicolons: It's not very uncommon to write concise one-liners - focus one ONE line - in the REPL when you want to do something quickly. For example importing and calling a function. This is a convenient one-liner in history then if you need to restart to apply code changes (reload() isn't particularly good if you changed multiple files).

But let's take a simple example: foo = "bar"; 2 * foo

This is formatted to two lines:

In [1]: foo = "bar"
   ...: 2 * foo
Out[1]: 'barbar'

Now that's a multi-line statement in the history, which IMHO is actually less readable. If you do it with an actual import and function call it's even clearer.

BTW: In Jupyter Notebooks autoformatting may be more useful since that's something you want to share (but even there one-liners may be perfectly fine sometimes). But in the simple ipython REPL? Nope...

[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".

2. 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.

3. 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.

[encukou]

@ambv:

Semicolons and backslashes are pretty uncontroversially discouraged in user code, no?

In modules, yes. But in IPython (7 and below), a semicolon will disable output:

IPython 7.26.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: 1 + 1;

In [2]: 1 + 1
Out[2]: 2

AFAIK, this is widely used in data processing (with Pandas), when the result of an expression is a huge table. Or with matplotlib+notebook, where the text __repr__ of a graph is usually not useful (and the graph is drawn separately).

BTW, this use of the semicolon is mentioned with the sphinx directive in IPython docs; I assume that should be changed?

[emirkmo]

Please revert this being the default. This is horrible for teaching purposes. It also mangles good pandas code for example. It’s not possible to go around to 200 students and have them disable this. Anybody who prefers something as strict as black can easily opt in.

Strict dogmatic code styling is an advanced use case that should not be enabled by default!

Thanks! 🙏

Edit: I didn’t do a full read of the issue before posting. Sorry if this was piling on. Always appreciate the work and efforts put into such a project as ipython that I used for years and years. Wanted to get my input in before bed after dealing with it over a zoom session with students. Cheers.

[ichard26]

(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).

I do not know whether you were already aware of this but we are aiming to mark Black as stable by the end of the month (hopefully, staying on time is hard in OSS). This mostly means Black's style won't change until the start of every year¹. Bug fixes and enhancements will be released as they're landed. I don't know what this means for IPython but I wanted to make sure you were aware.

---

And finally, @Carreau if you feel you need to step back for a little bit then go for it. OSS is hard, and I understand the frustration when a) the decision you puts lots of effort in ended up being more controversial than prerelease polling suggested, and b) the dogpiling this mess trends towards. The world will not end if IPython 8.1 does not get released by the end of January (fwiw, we were quite hesitant doing black releases for a really long time, like over 8+ months without a release and yet today we're still doing ok 🙂 ).

Thank you for all your hard work on IPython and Jupyter!

Footnotes

1. to everyone who is worried about the poor math handling being locked in for a year, I don't have anything to promise but we are indeed aiming to improve power operation formatting before the stable release: https://github.com/psf/black/pull/2726 ↩

[barraponto]

This feature would be very welcome as a plugin.
Typing pip install ipython[black] or pip install ipython ipython-black would be the best way to opt-in to this amazing feature (as it would take no configuration other than installing the plugin).

[eirnym]

@FlaviovLeal

Ha! I understand your frustration. However, I don't share it.

I have a two major problems with iPython configuration.

1-st is configuration file and sync

For me editing iPython's configuration and keep it similar on machines I work on is quite hard. I don't say that when I teach or present a new tool it's kind awkward to tell "please, use this configuration as defaults are no good anymore".

2ns issue is configuration file is not a simple config. It's not a language agnostic file like INI, but it's an executable. I agree, that's it's more flexible this way, but… I don't trust executable code and wish to avoid it as much as possible.

And now iPython tool changes sane default to forcibly use black. This formatted is good enough for general Python, but not every single code and way to use it.

You tell that "nobody knows"? How do this project advertises its' options? "Generate default config file" command? Man page? Simple HTML documentation? Wiki Page? An article on a popular blog platform or even Twitter? I don't see "most useful configuration options for iPython or similar help pages.

I see only complex html version "go write a code and we don't care about your problems with lack or misplaced of information". And yes, even I have black as a formatter I want to be able to configure it for iPython.

You tell that you changed in alpha/rc/beta and so on and nobody complained? I don't know many people around me who really use any beta software, even if this software is indeed stable. Python itself is a language, where you have to check next version to make your library or tool to be compatible on day 1. IPython is a tool, which meant to be stable. If tool is meant to be stable, it means for me that defaults won't change without any security or vulnerability issues or at least without a very bold message shown to a user every time (s)he's running a tool

[eirnym]

@ambv having black installed or available in path doesn't mean I want to use it for iPython.

Also black constancy isn't really good for Pandas and other scientific applications. Yes, pep8 format is needed in one way or another, but not as forcibly as black applies. There's a lot of tricks you learn only by writing and solving by try and error, where black is like an elephant in Chinese shop. And even here I won't force its usage.

I'd suggest to write a tool to format code as scientist would want to, keeping semicolons, keeping pandas-specific formatting and so on. And this tool most definitely won't be any good for general python programming. Even both tools would produce pep8 compatible code, but it would look different.

[OpenBagTwo]

In modules, yes. But in IPython (7 and below), a semicolon will disable output

Hasn't the pythonic way to do this always been:

_ = 1 + 1

?

Also black constancy isn't really good for Pandas and other scientific applications.

I cannot even begin to tell you how much I disagree with this, speaking as a data scientist who works a lot with analysts who are new to python.

Pandas is a great library, but it almost encourages the writing of unreadable code. Since enabling black auto-formatting, I have found my own data processing to be 200% more legible (and has made typos, bugs and flaws 500% more obvious).

Beyond the toll on tech debt and throughput, needing to worry about the "proper" way to format code has a real psychological toll. An analyst once handed off a notebook containing a few hundred lines of code. They apologized for the "how bad" their code was. Literally all I had to do was run, black-nb, and suddenly I was staring at some of the most careful, clever and well-constructed python I'd ever seen, albeit with a ton of copy-paste (DRY would arguably have been an antipattern for this use case).

Similarly, I set up all of our team repos--including where we store our "lab notebooks"--to run black (and isort) via pre-commit. I expected the junior team members to struggle with that. Instead, the feedback I received was gratitude that they didn't really have to learn or worry about all the various PEP8 rules; and relief that they didn't have to apply a dozen formatting rules during PRs.

In these ways, black-by-default leads not only to an essentially free jump in code quality and an easy ramp for new python programmers to get comfortable with the language's code conventions, but a demonstrable empowerment of coders of all skill and experience levels to feel confident that their code is worthy of sharing without feeling self-conscious just because they don't always know the best place to put line breaks.

Thank you, IPython team, for doing this. This is a huge step for software integrity and for making python more accessible to the vast majority of programmers and python users who will benefit from having linted code out of the box. Let the experts who "know what they're doing" and want the software to "get out of their way" build their own customizations and workarounds.

[ThiefMaster]

Again I think notebooks are completely different from the ipython REPL... for the latter I think it's not a good feature, for notebooks it seems way more reasonable and possibly useful.

BTW, regardless of the future defaults, how about disabling quote normalization? I think that's the single most controversial choice of black and least useful one in this context as well.

Also, in case the feature remains enabled by default: IIRC. sometimes the ipython config isn't loaded depending on how an application embeds it. Not sure if that's still the case with recent versions but if yes that'd mean you may sometimes not be able to disable it easily in every tool that embeds an ipython REPL. A simple env var to disable auto formatting could help in that case...

[ztane]

@ThiefMaster yeah the notebooks have toolbar, menu etc, wherein you could disable the reformatting. Or enable it, as you wish, easily. Or even have a different cell type for autoformatted code and so on.

[davidhalter]

@Carreau I can understand what you are going through. I feel like it was a perfectly fine decision to release 8.0 with black as a default. I have had similar experiences with Jedi, where some people got really frustrated with my decisions. It's probably perfectly fine to revert this change in 8.1 if you want to.

As an upside I would say that most people in this thread were nice and they actually care about IPython, so I hope you do not get too frustrated. Personally I don't do too much alpha/beta/RCs, because people don't use those anyway. So if it's too much work, I would probably just ditch that part. I feel like it's perfectly fine to just test default changes in major versions, because that's where you get feedback.

So whatever you do, note that 80% probably don't care at all about this default, 10% like it and will therefore never find this thread and 10% are against it. I personally would not enable it by default for two reasons:

• Some people get annoyed by this behavior and complain
• You get more bug reports, because it's an additional feature

Both are just wasting maintainer time and your mental sanity :) But feel free to do whatever you think is the right decision here.

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.

I feel like a lot of those people are beyond saving :) I'm seeing more and more non-programmers using IPython/Jupyter in my circles, which is a good thing.

[willingc]

First and foremost, thank you @Carreau for stewarding IPython for many, many years. It's a useful REPL for scientific programming and beyond, because of your maintainer efforts and the time of many contributors.

I'm very happy that people have found IPython useful in education and in their day-to-day work. For over a decade, IPython and Project Jupyter have worked to enable interactive computing and computational narratives. To the many users and volunteer contributors, I thank you.

I have huge respect for @Carreau and the work that he has put in over the years. He has generously given many personal hours to maintain IPython.

In this challenging time with Covid, it's very important to be respectful of the people behind the projects. Please be thoughtful in your comments and suggestions and as generous with your appreciation as your criticism. We are truly working for the same goal, and we will be far more successful doing it thoughtfully.

[meawoppl]

I would donate $100 to see this PR closed unmerged.

AFAICT, there isn't anyone objecting to this change that that couldn't have better spent their time setting a single bit to restore the original behavior that they prefer.

[rhettinger]

A problem that is about to surface is reformatting code in existing, published research and tutorials for Jupyter notebooks. When a someone views the notebooks and runs them, the reformatting will defeat the original author's careful formatting. Note, this is something the author cannot control. It happens on the client side.

Here are some examples from Peter Norvig's famous Probability Tutorial:

@@ -1,6 +1,4 @@
-def joint(A, B, sep=''):
-    """The joint distribution of two independent probability distributions.
+def joint(A, B, sep=""):
+    """The joint distribution of two independent probability distributions.
     Result is all entries of the form {a+sep+b: P(a)*P(b)}"""
-    return ProbDist({a + sep + b: A[a] * B[b]
-                    for a in A
-                    for b in B})
+    return ProbDist({a + sep + b: A[a] * B[b] for a in A for b in B})

@@ -1,4 +1 @@
-S2b = {'BB/b?', 'BB/?b',
-       'BG/b?', 'BG/?g',
-       'GB/g?', 'GB/?b',
-       'GG/g?', 'GG/?g'}
+S2b = {"BB/b?", "BB/?b", "BG/b?", "BG/?g", "GB/g?", "GB/?b", "GG/g?", "GG/?g"}

In both cases, the reformatting defeats the author's effort to format data in a way that best communicates either what the code is doing or the structure of the data.

This applies broadly. Perhaps critical research using Python2.7 will be unaffected, but most tutorials and scientific papers will now look different to different viewers.

[rhettinger]

Here's an example from the statistics tutorial:

-posterior_male = (prior_male * height_male.pdf(ht) *
-                  weight_male.pdf(wt) * foot_size_male.pdf(fs))
+posterior_male = (
+    prior_male * height_male.pdf(ht) * weight_male.pdf(wt) * foot_size_male.pdf(fs)
+)

-posterior_female = (prior_female * height_female.pdf(ht) *
-                    weight_female.pdf(wt) * foot_size_female.pdf(fs))
+posterior_female = (
+    prior_female
+    * height_female.pdf(ht)
+    * weight_female.pdf(wt)
+    * foot_size_female.pdf(fs)
+)

Note how the two posterior computations are no longer parallel to one another. When this happens in published Jupyter tutorials, it lowers the quality of presentation. Again note that this cannot be controlled by the author. Every reader of the notebooks would have to explicitly opt-out of reformatting the author's original code.

[mikepqr]

A problem that is about to surface is reformatting code in existing, published research and tutorials for Jupyter notebooks. When a someone views the notebooks and runs them, the reformatting will defeat the original author's careful formatting. Note, this is something the author cannot control. It happens on the client side.

@rhettinger I share your concern that notebooks are different to modules. They are often intended to be executed rather than edited. Reformatting an existing notebook simply when a user executes it would therefore be a drastic change, if that were to happen.

But if I understand correctly, it hasn't happened. #13397 is a change to the IPython REPL (i.e. IPython/terminal/interactiveshell.py). It does not affect notebooks at all! I cannot reproduce the behavior you describe in a notebook, and the diff you post is not the diff of a notebook file but rather a diff of python code. Could you be more specific about the steps to reproduce what you posted?

[OpenBagTwo]

I am incredibly confused by all this talk about how these changes would negatively impact classroom instruction and reference documentation. Any programming book I've read or data science tutorial I've ever found is written with the knowledge that languages evolve--especially when we're talking about packages outside the standard library. How many guides had to be rewritten or were rendered obsolete when pandas deprecated--and soon after removed--.ix? I personally spent at least two weeks updating a SQLAlchemy toolkit to conform to the new 2.0 API. And how often does boto break backwards compatibility?

In my experience, all the guides and tutorials I've found explicitly specify their versions and oftentimes contain instructions for setup, usually in my space in the form of a conda environment.yml. I won't even get into how containerization makes things even easier by making sandbox creation literally push-button. So if auto-formatting is really that big of a deal for your class--aren't your setup instructions already pinning your version of python, IPython and what-have-you? If not, well, that's really way more of a problem than anything else you're bringing up. Or have you not been following the news?

Edit / Aside wrt this behavior in notebooks

I cannot reproduce the behavior you describe in a notebook, and the diff you post is not the diff of a notebook file but rather a diff of python code.

Haha, phew--I thought I was the only one and figured there was a build or something that hadn't made it to conda-forge yet.

If you want to see how a Jupyter notebook would reformat, jupyter_code_formatter is my everything--and even there it's push-button, not automatic. And since I referenced pre-commit before, see also: black-nb.

[eirnym]

@mikepqr ipython, an REPL, is a great tool to show off things if you don't want to create a Jupyter Notebook. Also I disagree with "one true <...>" thing where dots in triangle brackets could be anything. Or like a quote or semicolon at the end.

Forcing me to format with black by default makes a tool I use for years much less valuable for me and my students then the simple python REPL.

The best solution I see from this dispute is to publish an official ipython-black package which just change the default to format using black and nothing else, leaving the setting inside iPython configuration for whom want to change it in their configuration files. And make it default if mounthly download report for a plugin is comparable to ipython itself

@meawoppl you can bribe maintainers, but you cannot bribe whole community

The most edge case of where this dispute can go further is a creation of a fork where this setting is off and the rest is just aligned with this repo. And this would be a quite problematic solution for the whole community and people involved.
This would lead to at least 2 repos, and community helping the project will actually struggle to where put efforts.

[mikepqr]

@mikepqr ipython, an REPL, is a great tool to show off things if you don't want to create a Jupyter Notebook.

Sure. I think you're missing my point, which is that:

• the change we're talking about reverting does not affect notebooks (AFAICT!)
• the scenario described in this comment does not happen (or at least I can't reproduce it)
• formatting of notebooks is not relevant to IPython (i.e. this repo)

[rhettinger]

Yes. I just confirmed this is IPython only. Am not sure why, but the auto-reformatting doesn't affect the Jupyter notebooks. So that bullet has been dodged.

[eirnym]

I don't miss your point and examples you mentioned are working just fine, eg forced to be reformatted.

At class I show students various tools and I prefer keep their mess intact if this doesn't go further to a program as it's a part of a learning process.

I also show various python features like semicolons, the quotes are the same, and many others.

Why _ = expression doesn't work for me to suppress the output? expression; doesn't modify the _ variable which is important in some cases.

[adeak]

@rhettinger you may have missed it among all the comments here, but the person who thought Black should be automatically applied to lines in the IPython CLI left a long comment here, with an explicit reference to your unfortunate choice of words that set this whole discussion off on the wrong foot.

At this point there's clear pushback from the community, with plenty of technically-reasoned support for why this ended up being a controversial move. If maintainers want to revert the feature they already have the technical feedback they need right now. Adding further examples doesn't add to the discussion; on the contrary, piling on will only dig deeper trenches. Especially so if your further technical complaints are not well-founded.

[Carreau]

I'm locking the conversation, there is no point in discussing this further.

There are sane factual reason to disable it by default being that reformatting is sometime factually wrong (semicolon, and magics without %). That is sufficiently problematic in itself.

So the next release will likely revert it, depending on the time I have, other things on my plate, and more important things for this repository (like fixing CI first to not block all the pending Pull-requests first).

I do not exclude to fix the magic and semi-colon problem and maybe re-enable black at some point in the future, even just because for some feature it seem the only way to get feedback and bug reports.

I would greatly appreciate any help to write better documentation, blog post on features, and getting feedback from the community, a better way to edit/persist Configuration in JSON files that has been supported for years. Why not a %web_config that does like fish or xonsh and pop-up a web-browser that let you pick options (hey it can even be made as a separate package), or have a TUI client.

Also please stop hitting or vilifying anybody, and please help testing downstream project by making sure CI tests are run with --pre and similar, there are much better way to spend our time by making sure everything works well for everybody.