Make the TerminalInteractiveShell class configurable. - #10373

As I said in the other issue, I wouldn't do this - I would subclass TerminalIPythonApp in rlipython and override init_shell there, so you start it with rlipython, not by configuring ipython.

As I said in the other issue, I wouldn't do this - I would subclass TerminalIPythonApp in rlipython and override init_shell there, so you start it with rlipython

That implies that all IPython wrapers and extensions that exists need to be updated to take an option instead of allowing it to be done globally. That seem like quite the task, and the annoyance for users.

As I said in the other issue, I wouldn't do this - I would subclass TerminalIPythonApp in rlipython and override init_shell there, so you start it with rlipython, not by configuring ipython.

Why weld something when it could be swappable?

Please consider why we're doing this in the first place: IPython 5.0 broke a bunch of people's workflows when it unilaterally moved away from readline to prompt toolkit without giving users the ability to fall back to old behavior. #10364 has a list of many of them, and proposed bringing back that code into IPython, which you (@takluyver) are strongly against. @Carreau is already making the compromise of not putting that code back into IPython, but instead proposes a straightforward ability for users who relied on the old behavior to install a package, set a config, and continue using IPython.

@meeseeksdev backport

Oops, something went wrong applying the patch... Please have a look at my logs.