Suggestions

1. use black on all the things and have a bot/ci that autoformat pull-requests. IE not fail on improperly formatted code to not annoy user. The main question is: do we run black at once on the full codebase ?

2. Drop Nose, test using Pytest. It's still a bit annoying as we are so far stuck on pytest 3, and moving to pytest 4 or 5 will be a significant effort. Some test still only run w/ nose (doctests) and need to be migrated.

3. Completer refactor... this can be a lot of work and is a change of API.

Suggestions:

• Resolve the issues with the completer (see #11804)

(please help me out with that by the way. I'm having trouble keeping it to work with external frontends)

Yes, that would be a good idea as well.

Suggestions:

• Remove deprecated color_scheme argument in core.debugger.
• Remove other deprecated items (esp. those deprecated before ipython5).
• Remove python 2 specific imports. I found reprlib, winreg, and tkinter with a search for py 2.

Suggestions

1. use black on all the things and have a bot/ci that autoformat pull-requests. IE not fail on improperly formatted code to not annoy user. The main question is: do we run black at once on the full codebase ?
   ...

Yes
It appears that it's possible to specify commits to be ignored by git blame by pointing blame.ignoreRevsFile to a file with the commit hashes corresponding to formatting commits.

• Remove python 2 specific imports.

That does not need to wait for 8.0 if they are 2.x only.

It appears that it's possible to specify commits to be ignored by git blame by pointing blame.ignoreRevsFile to a file with the commit hashes corresponding to formatting commits.

I saw that it's new in git 2.23; I haven't found the default name for this ignore file; it would be nice for users to not have to explicitly configure git; so if you find how to do that; it would be nice.

... it would be nice for users to not have to explicitly configure git; so if you find how to do that; it would be nice.

What about a repo-specific .gitconfig that includes this file name, and a one-time setup script that runs git config --local include.path ../.gitconfig?
The only other option is to change git so there is a default file.

I recently implemented a variant of the idea in my previous post:

• Put the revs to ignore in .git-blame-ignore-revs (see this post for rationale on the name, and confirmation that there's no default file name).

# When making commits that are strictly formatting/style changes, add the
# commit hash here, so git blame can ignore the change.
# see docs for more details:
# https://git-scm.com/docs/git-config#Documentation/git-config.txt-blameignoreRevsFile

<full commit hash>  # initial black-format
<full commit hash>  # rename something internal

• Create a batch script (and corresponding shell script) configure-git-blame-ignore-revs.bat containing:

rem other config options for blame are markUnblamables and markIgnoredLines.
rem see docs for more details:
rem https://git-scm.com/docs/git-config#Documentation/git-config.txt-blameignoreRevsFile

git config blame.ignoreRevsFile .git-blame-ignore-revs
git config --get blame.ignoreRevsFile

• Explain in developer docs.

I'm more and more convinced that this would be helpful.
If you want to send a pull-request that add these scripts in tools and update the readme that would be nice. At least we can focus the discussion in there; and once we run black on something we can decide to update this file. I'm guessing we can also likely look at the version of IPython; and if its .dev; ask user to run specific commands.

Master is now going to be IPython 8.0. no target date yet, but API changes are now game.