New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the TerminalInteractiveShell class configurable. #10373

Merged
merged 1 commit into from Apr 10, 2017

Conversation

Projects
None yet
4 participants
@Carreau
Member

Carreau commented Mar 2, 2017

Should allow custom frontend in separate packages.

cc @takluyver, @ivanov


That's sufficient for me to get the basics working.

rlipython

@Carreau Carreau modified the milestone: 6.0 Mar 2, 2017

@takluyver

This comment has been minimized.

Show comment
Hide comment
@takluyver

takluyver Mar 3, 2017

Member

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.

Member

takluyver commented Mar 3, 2017

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.

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Mar 3, 2017

Member

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.

Member

Carreau commented Mar 3, 2017

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.

@ivanov

This comment has been minimized.

Show comment
Hide comment
@ivanov

ivanov Mar 3, 2017

Member

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.

Member

ivanov commented Mar 3, 2017

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.

Show outdated Hide outdated IPython/terminal/ipapp.py
interactive_shell_class = Type(
klass=object, # use default_value otherwise which only allow subclasses.
default_value=TerminalInteractiveShell,
help="Class to use to instantiate the TerminalInteractiveShell object. Usefull for custom Frontends"

This comment has been minimized.

@jasongrout

jasongrout Mar 4, 2017

Member

"Useful"

@jasongrout

jasongrout Mar 4, 2017

Member

"Useful"

Make the TerminalInteractiveShell class configurable.
Should allow custom frontend in separate packages.

@Carreau Carreau merged commit c2b5745 into ipython:master Apr 10, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@Carreau Carreau modified the milestones: 5.4, 6.0 Apr 10, 2017

@Carreau

This comment has been minimized.

Show comment
Hide comment
@Carreau

Carreau Apr 10, 2017

Member

@meeseeksdev backport

Member

Carreau commented Apr 10, 2017

@meeseeksdev backport

@meeseeksdev

This comment has been minimized.

Show comment
Hide comment
@meeseeksdev

meeseeksdev bot Apr 10, 2017

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

meeseeksdev bot commented Apr 10, 2017

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

@Carreau Carreau deleted the Carreau:tis-configurable branch Apr 18, 2017

Carreau added a commit to Carreau/ipython that referenced this pull request Apr 18, 2017

Backport PR #10373 on branch 5.x
Make the TerminalInteractiveShell class configurable.

@Carreau Carreau added the help wanted label Apr 20, 2017

Carreau added a commit that referenced this pull request Apr 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment