Skip to content
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

Should we remove self-references? #11932

Open
gigaj0ule opened this issue Oct 31, 2019 · 4 comments · Fixed by #11938
Open

Should we remove self-references? #11932

gigaj0ule opened this issue Oct 31, 2019 · 4 comments · Fixed by #11938

Comments

@gigaj0ule
Copy link

I noticed that when I tried to run iPython's interactive shell as a local dependency

from . import ipython

A lot of the files in the program have self-references that expect ipython to be a global package. For example in interactiveShell.py...

from IPython.core.events import EventManager, available_events

But if we replace this with,

from ..core.events import EventManager, available_events

or

from .events import EventManager, available_events

the self-reference is eliminated, and we can import the library and it works without iPython being defined in the global namespace.

@Carreau
Copy link
Member

Carreau commented Oct 31, 2019

I think that is a reasonable thing to do.

In general there is a long standing issue to try to remove anything that rely on global state in IPython so that for example a process can embed to IPython kernels or debugger.

It's just a lot of work, and none of the core dev have found time to move forward on this.

If you wan to update some of those and send a pull-request, we can see if the test are passing.

I'm also trying to do a monthly release so we can do only a couple of change every month and see how it affect users.

@gigaj0ule
Copy link
Author

I tried doing this a bit last night before realizing that indeed there's going to be a lot to do.

It looks like there is a combination of low hanging fruit such as,
from Ipython import X
which is very easy to fix.

But there are a lot of references to iPython in various strings which might be harder depending on where those strings are executed.

When I have the free time to do it I will get started on a branch that at the very least gets rid of the low hanging fruit.

@Carreau
Copy link
Member

Carreau commented Nov 3, 2019

When I have the free time to do it I will get started on a branch that at the very least gets rid of the low hanging fruit.

Thansk that would be great. Even if it's a single import, it's always a small step in the right direction.

@Carreau
Copy link
Member

Carreau commented Nov 12, 2019

A bunch of the imports have been done in #11938 , I believe there is still some code that will rely on global IPython; so we may need some more fixes, so reopening.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants