Liaise with Spyder devs to integrate newer IPython

[takluyver]

Pinging @ccordoba12

In a blog post last year, Pierre Raybaud said "The more I think about it (and the more I spend time on it), the more I doubt that there will ever be a decent support of IPython >=v0.11 in Spyder's console." We assume this is also why Python(x,y) ships with a version of IPython based on the old 0.10 series.

We liaise with them and work out any issues to ensure that Spyder can effectively use a newer version. We think the new architecture should make it easier to integrate with IDEs, so it's a point of concern that an IDE prefers to stick with the old version.

[ccordoba12]

Thanks a lot @takluyver for having us in mind! Things in our front have
not been progressing as rapidly as for you guys, but we are coming there :-)

First, let me clarify what Pierre meant in that post. Given that you
changed how gui event loops are handled in >=0.11, the solution we had
for 0.10, i.e. embedding terminal IPython using InteractiveShellEmbed,
was not technically possible anymore. I don't know the full details, but
that's what Pierre explained to me.

The next logical step was to try to embed qtconsole, which he did
shortly afterwards. The integration started as a mere proof of concept
and has continued to improve over time (especially since you released
0.12). With Spyder 2.1.11 you can open several consoles at once, send
code from the editor to them and inspect the current namespace using our
variable explorer.

As for Python(x,y), well I'm not a developer of it, but I think Pierre
is waiting for Spyder 2.2 to be ready to do the switch to 0.13. That's
because we've been working really hard to provide a nice and rich way to
configure qtconsole using our Preferences page and minimal terminal
effort. I'm quite happy with what we have accomplished: every console
can be configured separately, the user can choose the font, pager and
completion widget sytle, decide if he wants pylab or not and which
backend to use, interrupt and restart the kernel, and a couple more
things, all inside Spyder.

I'm also happy to say that we are about to finish our integration (right
now I'm working to let users select a profile, and there are some more
things left). However, it'll be great if you guys could download our
default repo, and make us suggestions and/or corrections of what we have
done so far. We also have a couple of doubts about your API, and this
issue seems the perfect place to solve them. I'll post them in the next
few days.

So many thanks again for bringing the issue forward, and I hope you like
our integration.

El 23/09/12 16:12, Thomas Kluyver escribió:

Pinging @ccordoba12 https://github.com/ccordoba12

In a blog post
http://spyder-ide.blogspot.co.uk/2011/09/no-ipython-v011-support-in-spyders.html
last year, Pierre Raybaud said "The more I think about it (and the
more I spend time on it), the more I doubt that there will ever be a
decent support of IPython >=v0.11 in Spyder's console." We assume this
is also why Python(x,y) ships with a version of IPython based on the
old 0.10 series.

We liaise with them and work out any issues to ensure that Spyder can
effectively use a newer version. We think the new architecture should
make it easier to integrate with IDEs, so it's a point of concern that
an IDE prefers to stick with the old version.

—
Reply to this email directly or view it on GitHub
#2425.

[PierreRaybaut]

As Carlos clearly explained, Spyder is compatible with IPython 0.12+ for a while now and is no longer blocking Python(x,y) in that respect (other parts of Python(x,y) still have to be upgraded to be compatible with recent IPython versions though, but that should be done in the near future).

[ccordoba12]

@takluyver, I think we are ready for a little advice about your API. Here are my questions:

1. Do we need to subclass IPythonQtConsoleApp as we did here just so we can create kernel managers and new widgets that use them for each one of our frontends?
2. Do we need to initialize the app before doing this? We defined a new method to do it here but we are not using it because we are unsure if it's necessary or not.
3. Does BaseIPythonApplication.initialize and IPythonConsoleApp.initialize do something else than reading your config files, i.e. ipython_config.py, etc?

We'd really appreciate your help and suggestions, because we are about to release 2.2 and want it to be rock solid! :-)

[takluyver]

I don't really feel qualified to answer any of those questions confidently. ;-) Pinging @minrk, who I think knows those parts better.

[minrk]

1. That depends on what you need it to do. If it needs to do anything differently not exposed by config, then yes. I expect you will.
2. It makes very little sense to have an Application without initializing it. initialize is basically everything. Generally to customize behavior, you override initialize in a subclass to do different things.
3. BaseIPApp loads config, ConsoleApp creates a KernelManager and starts a Kernel. If you don't want these to happen, then don't call them (BaseIPApp is probably important, ConsoleApp may not be).

Initialize is where approximately everything happens when creating an IPython Application. There are three steps to start any IPython app:

1. app = AppClass.instance() # creates the app
2. app.initialize([argv]) # reads config, instantiates objects - pretty much everything
3. app.start() # begins eventloop, usually trivial

If I understand correctly, your app subclass should look something like:

class IPythonApp(IPythonQtConsoleApp):
    def initialize(self, argv=None):
        BaseIPythonApplication.initialize(self, argv=argv)
        # disable creation of first KernelManager/Kernel, qt elements, and signal handlers

...
app = IPythonApp()
app.initialize(['--pylab', 'inline'])
widget = app.new_ipywidget()

That said, since you use approximately nothing of the configuration,
it may make more sense to skip the Application subclass altogether,
and just create KernelManagers and widgets directly.

[ccordoba12]

Thanks a lot @minrk for your clarifications. At the end we decided not to subclass IPythonQtConsoleApp because, as you said, we weren't loading your config files through it. The problem is that if we ran app.initialize then all frontends would have the same config and it wouldn't be possible for the user to modify it using our Preferences page.

Nevertheless, we are loading your config directly (by reading your files) and merging it with ours, like here.

You can close this issue now, thanks.

[minrk]

Thanks for the update.