[IPython-dev] gsoc with ipython
Wed Dec 8 09:53:51 CST 2010
On Mon, Dec 6, 2010 at 12:40 AM, Fernando Perez <email@example.com>wrote:
> Dear Daniel,
> On Wed, Nov 24, 2010 at 3:19 AM, Daniel Cracan <firstname.lastname@example.org> wrote:
> > I am a student at a technical university, and I would be interested in
> > for the IPython project at gsoc this summer.
> > I thought it would be much better if I got to know a bit more about the
> > project, before applying for it at gsoc.
> > So if there is anyone willing to point me to the right direction I would
> > appreciate that very much.
> I'm very sorry for the late reply, indeed as Erik indicated (thanks
> for chiming in!) it was just a matter of being very swamped with 'real
> life'. But I'm glad to have you here, and indeed we have now in
> ipython a lot of potential for new contributions. There's still real
> work to be done to 'land' the new zmq-based architecture in a fully
> stable release, but I hope we'll be able to make headway again into
> that soon. And that means the time is right to start thinking about
> gsoc projects.
> I'm going to list a few things that need doing, for some of these
> someone has already made a start but they aren't completed yet. But
> this is just so you get a sense of what's 'on the table'. The best
> contributions come always from matching a project's needs with the
> interest of the student, so feel free to pick something that is close
> to what *you* like and have skills for. We can then help get you
> started, so that by the time the gsoc rolls around, you have already
> some momentum going. In no particular order:
> - allowing the new Qt console to work in a single process. This may
> appear paradoxical (since we did all that work to be able to run in
> *two* processes), but there are scenarios where someone may want to
> embed an IPython rich widget inside an existing application that has a
> namespace to be interactively manipulated. Mayavi is a prime example
> that does that, and right now it would not be able to use our console,
> since the Qt widget expects to be a separate process.
The Mayavi embedding is possible using the current two process code and I
think that most usage scenarios like that will be handled much better in the
two process model. While I agree that some people will want to have a
single process IPython widget, I think they will always be quite unsatisfied
with the result (because of the blocking nature of everything) and try to do
nasty unthreadsafe hacks to get around those limitations.
> - continuing work on the html frontend that James Gao started:
> I haven't talked to James recently, and he may be able to find time to
> push forward again, so obviously we'd first sync with him before
> proceeding. But I expect this to be a fair amount of long-term work,
> so even with James' foundation in place, there will be plenty more to
Definitely lots of work in this area.
> - Allowing the html notebook and the Qt widget to use the matplotlib
> html5 backend, to get fully interactive windows inline. I don't know
> enough about Qt to be really sure if this is even possible, just an
> idea right now.
> - Develop a curses frontend. Wendell Smith discussed this a while ago
> and has some thoughts on the matter, but I don't know if he has made
> significant inroads; you may want to ping him first.
This would also be nice.
> - Work on the parallel parts: Min Ragan-Kelley has made phenomenal
> progress recently on this, but it's possible that despite his
> super-human abilities, he might still have more ideas than time to
> code them up. Now with the zmq support we have fairly ambitious plans
> for what can be done with ipython, so there will be plenty of work on
> this front.
Again, there is plenty of work to do on his front.
I can think of a few more as well:
- Get the two process terminal based IPython work really well.
- Improvements to the existing qtconsole. The sky is the limit here.
- Create a qt notebook frontend.
> This is just a starter list, let us know if any of it sounds
> interesting/appealing to you and we'll direct you with a bit more
> precision then.
> Regards, and welcome to the project!
> IPython-dev mailing list
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev