Allow starting TerminalInteractiveShell more than once

[minrk]

1. always start with keep_running=True in interact(), which avoids interact() being a no-op on all runs after the first.
2. don't close eventloop at end of mainloop (not sure this is the right thing to do)
3. pass self, not self.Completer to PTCompleter, to ensure that it's always hooked up to shell.Completer, which can be replaced over time (pudb).

cc @Carreau, @takluyver for the right thing to do about _eventloop.close(), since I doubt this is the right thing. Maybe register close with atexit.register?

cc @inducer this fixes inducer/pudb#193

[Carreau]

gruml gluml change of API.. gruml, gruml but I see the reason.
Can we check the type of shell and print a deprecation warning if it's a Completer ?

[minrk]

Not every internal utility class is a public API, so I have no qualms changing this one. I can make it backward-compatible, though.

[minrk]

Added now in a fully backward-compatible way, and explicitly declared the module as private APIs.

[Carreau]

cc @Carreau, @takluyver for the right thing to do about _eventloop.close(), since I doubt this is the right thing. Maybe register close with atexit.register?

Probably, or should we have an event loop "reference counting" and a with eventloop context manager that hold the eventloop ?

[takluyver]

Let's add it to the packages skipped for the API docs, in the list here.

[takluyver]

In fact, here.

[minrk]

Done.

[minrk]

should we have an event loop "reference counting" and a with eventloop context manager that hold the eventloop ?

I don't think that quite works because it seems like the refcount would never be anything other than one after the class is instantiated, since the loop is setup in __init__, and shouldn't be closed until the object is garbage collected (atexit or __del__). It's not recursive, so the count doesn't go up, it's starting and stopping the same IPython instance once in a while.

[takluyver]

I've just had a look at the prompt_toolkit code, and it doesn't look like there should be any ill effects of not calling eventloop.close(). Some fds will remain open, but you probably only have one InteractiveShell object, so a few fds lingering shouldn't be a problem.

If we do call it anywhere, I think __del__ would be the best place. That assumes that no-one is taking a reference to the event loop and using it outside of the shell object, but I think that's probably safe. Or maybe prompt_toolkit should have a __del__ method on the event loop classes to clear up their fds. (@jonathanslenders)

[minrk]

I tried putting it in __del__, but it doesn't seem to ever be called, perhaps due to circular references/global links created between pt and/or IPython.

[takluyver]

There certainly are going to be circular references through IPythonPTCompleter and TerminalInteractiveShell.inputhook. But recent versions of Python should be able to break the cycle and call __del__.

[minrk]

Python 3.5 isn't recent enough, at least.

[takluyver]

I've just tested with a __del__ method on TerminalInteractiveShell, and it does get called when the interpreter (3.5) exits. I was doing this to check that I hadn't misunderstood something. I don't think it's terribly important to do cleanup in __del__, and it would be better done in Eventloop.__del__ anyway. So I'm merging this as is.

[minrk]

've just tested with a del method on TerminalInteractiveShell, and it does get called when the interpreter (3.5) exits

I did the same and it didn't (and again just now, with conda CPython 3.5.1 on OS X), so it's at least not a trustworthy event.

Agreed on the other points, though. Thanks!