Status of Reinteract
pbouda
as I like Reinteract very much I wanted to ask if there is any
development on the project...? I am working for a scientific project
at the University of Munich, we are developing Python modules for
quantitative linguistics and Reinteract was one of the things we
wanted to use in courses to demonstrate our modules. But we are
developing for Python 3 now, so we would need a version of Reinteract
with Python 3 support. I just ported two libraries to Python 3, and I
am willing to help with the migration, if you think it makes sense...
Another question is how difficult it might be to port the gtk/gobject
dependencies of Reinteract to PyQt or PySide? What does Reinteract use
gobject and gtk for? I am not too familiar with gobject; do you think
a port makes sense and is doable? I did a lot of PyQt programming, and
would really like to have a nice Qt-GUI for Reinteract...
Best,
Peter
Robert Schroll
> as I like Reinteract very much I wanted to ask if there is any
> development on the project...?
There's fairly little going on at the moment, I'm afraid. But don't let
that dissuade you from contributing! Some thoughts about the future can
be found here: http://www.reinteract.org/trac/wiki/RoadMap
> I am working for a scientific project
> at the University of Munich, we are developing Python modules for
> quantitative linguistics and Reinteract was one of the things we
> wanted to use in courses to demonstrate our modules. But we are
> developing for Python 3 now, so we would need a version of Reinteract
> with Python 3 support. I just ported two libraries to Python 3, and I
> am willing to help with the migration, if you think it makes sense...
Obviously, Reinteract will have to be ported to Python 3 if it is to
survive. matplotlib and numpy are making the transition now, so it's
about time for Reinteract to follow suit. The difficulty, as I
understand it, comes from the GTK bindings. Reinteract uses the
GTK2/pyGTK bindings, which will not be ported to Python 3. The way
forward is with the GTK3/pyGI bindings, which exist for both Python 2
and 3. So I think we need to first port from GTK2/pyGTK to GTK3/pyGI
and then port to Python 3. (Anyone who knows more about this should
correct me if I'm mistaken.)
There are tools to help with both of these transitions, but I don't know
how well they'll work in this case. The non-GUI-parts of Reinteract
seem to have good test coverage and Reinteract already uses unicode
throughout, so I suspect the Python 3 transition will not be too
difficult. But I don't have any idea about how bad transitioning the
bindings will be.
>
> Another question is how difficult it might be to port the gtk/gobject
> dependencies of Reinteract to PyQt or PySide? What does Reinteract use
> gobject and gtk for? I am not too familiar with gobject; do you think
> a port makes sense and is doable? I did a lot of PyQt programming, and
> would really like to have a nice Qt-GUI for Reinteract...
One idea that has been floated in the past is splitting the front and
back ends. If this were to happen, porting the only the front-end to Qt
would obviously be easier. This may be worth thinking about as part of
the pyGTK/pyGI transition - a pyGI frontend could be created in addition
to, instead of in place of, the pyGTK frontend.
I've been thinking a bit about this split, in the context of getting
each worksheet running in its own process. This would:
- eliminate crosstalk between worksheets in shared modules
- isolate the GUI from crashes or freezes in worksheet execution
- maybe allow different worksheets to use widgets from different backends
It's the ability to embed widgets in worksheets that has me stuck,
though. The obvious way to handle this would be with gtk Plugs and
Sockets. But the docs say, "The GtkPlug and GtkSocket widgets are
currently not available on all platforms supported by GTK+," which I
suspect is code for, "Only works on X." Owen, do you have further
thoughts on this?
Anyway, I hope I haven't scared you off with details. The transition to
Python 3 will probably end up being a big project, but I don't think it
should be a particularly *difficult* one. Hopefully Owen can chime in
with his thoughts and maybe we can come up with a plan forward.
Robert
Owen Taylor
I'm at least hoping that I'll have some significant time to work on reinteract in the near future. We'll see. It's certainly something they I'm still quite interested in despite the lull in development over the last few years.
A little while I did a not finished but pretty much fully functional port to gtk 3 and pygobject-introspection in a local branch. It only took a day our so. So that's not really a blocking issue in the transition to Python 3. Bigger issues are: is python 2 suport still needed? Scipy and numpy. Getting new versions of everything working together on Windows and OS X and making binary distributions. And simply upgrading the syntax tree and tokenization in Reinteract for python 3.
The frontend/backend split is definitely interesting to me. I'm doing some travelling at the moment, and in pare minutes picked up an experiment I started earlier at a HTML based frontend for Reinteract; not nearly usable yet, but if I can get it to work it will be a good place to experiment with protocol issues, as well as interesting in its own right.
Certainly with a HTML frontend, the actual data display has to live in the frontend, and data has to be sent from the backend to the frontend, either as raw numbers, or as some sort of intermediate format like SVG. For that reason, I don't really see something like GtkPlug/GtkSocket as being particularly good fit - it really would work only for a GTK+ (or at least X) based frontand and backend on Linux.
You could do the granularity of the backend at different levels; I was thinking of doing it at the notebook level, to allow sharing data sets between different worksheets, but per worksheet seems possible as well.
- Owen
> You received this message because you are subscribed to the Google Groups "Reinteract" group.
> To post to this group, send email to reint...@googlegroups.com.
> To unsubscribe from this group, send email to reinteract+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/reinteract?hl=en.
>
Robert Schroll
> A little while I did a not finished but pretty much fully functional
> port to gtk 3 and pygobject-introspection in a local branch. It only
> took a day our so. So that's not really a blocking issue in the
> transition to Python 3.
Good to hear. Of course, a day of work for you is probably like two
weeks of futzing for me.
> Bigger issues are: is python 2 suport still needed?
I'd rank it as nice but not crucial. If we could gather things together
for one last Python 2 / pyGTK release, that ought to sate people until
they move to Python 3. If it would help, I'd be willing to maintain a
maintenance branch for this version and let others focus on a new version.
> Scipy and numpy.
Numpy supports Python 3 since 1.5.0 (8/2010); Scipy since 0.9.0 (2/2011)
> Getting new versions of everything working
> together on Windows and OS X and making binary distributions. And simply
> upgrading the syntax tree and tokenization in Reinteract for python 3.
>
> The frontend/backend split is definitely interesting to me. I'm doing
> some travelling at the moment, and in pare minutes picked up an
> experiment I started earlier at a HTML based frontend for Reinteract;
> not nearly usable yet, but if I can get it to work it will be a good
> place to experiment with protocol issues, as well as interesting in its
> own right.
Have you looked at the new ipython? They've split it into a
front/back-end model, which allowed them to write a Qt frontend that can
display HTML, SVG, and PNG results inline. It's complete enough to be
able to provide tooltips with docstrings, so it might be a useful
starting base for Reinteract.
>
> Certainly with a HTML frontend, the actual data display has to live in
> the frontend, and data has to be sent from the backend to the frontend,
> either as raw numbers, or as some sort of intermediate format like SVG.
> For that reason, I don't really see something like GtkPlug/GtkSocket as
> being particularly good fit - it really would work only for a GTK+ (or
> at least X) based frontand and backend on Linux.
Being able to display interactive widgets is one of the killer features
for Reinteract for me, so I'd hate to loose that. Some ideas:
- Have some negotiation of content type. An X frontend could accept a
GtkPlug/Socket type, while a HTML front end requires a PNG or SVG file.
- If the Broadway GDK backend is still alive, that might be able to be
used to embed GTK widgets as HTML in a variety of front-ends.
- If the backend is willing to act as a webserver, something like the
matplotlib HTML5 backend (http://code.google.com/p/mplh5canvas/) could
be used.
But all of these complicated the model of having a backend that just has
to worry about executing code.
>
> You could do the granularity of the backend at different levels; I was
> thinking of doing it at the notebook level, to allow sharing data sets
> between different worksheets, but per worksheet seems possible as well.
The crosstalk between worksheets in the same notebook is surprising at
first, but it can come in handy at times. I could go either way on this
one.
Robert
pbouda
still did not look into the code of Reinteract, maybe I can spend a
few hours of this week on this. I am going to EuroSciPy next week, and
hope to learn more about the new version IPython and get some ideas.
About the backend/frontend communication: maybe Reinteract can use a
general (and light-weight) socket/pipe library for this, as I also
think that Reinteract should not depend on Gtk or anything similar.
Maybe a websocket implementation...
About the gobject-introspection (without knowing anything about the
internals ... ;-)): do you think it would be possible to abstract away
from a particular introspection implementation? PyQt or PySide do
provide it, too. I am currently experimenting with Jython and
IronPython, and it would be nice to have Reinteract running under
Jython, at least (with a Swing GUI, for example; and IronPython with
Silverlight, :-)). Java/JVM 7 provides good support to scripting
languages now and there are so many (scientific) Java libraries and
tools around that I want to use with Reinteract. I was thinking about
using a Clojure REPL (like Incanter) for Java stuff, but mixing in
Python libraries would make things easier and we definitely want to
use Python for teaching.
Best,
Peter
Owen Taylor
>> Bigger issues are: is python 2 suport still needed?
>
> I'd rank it as nice but not crucial. If we could gather things together for
> one last Python 2 / pyGTK release, that ought to sate people until they move
> to Python 3. If it would help, I'd be willing to maintain a maintenance
> branch for this version and let others focus on a new version.
This sounds like a good idea.
[...]
>> The frontend/backend split is definitely interesting to me. I'm doing
>> some travelling at the moment, and in pare minutes picked up an
>> experiment I started earlier at a HTML based frontend for Reinteract;
>> not nearly usable yet, but if I can get it to work it will be a good
>> place to experiment with protocol issues, as well as interesting in its
>> own right.
>
> Have you looked at the new ipython? They've split it into a front/back-end
> model, which allowed them to write a Qt frontend that can display HTML, SVG,
> and PNG results inline. It's complete enough to be able to provide tooltips
> with docstrings, so it might be a useful starting base for Reinteract.
It's worth a look, certainly, though I'd expect the network protocol
flow to be pretty different.
>> Certainly with a HTML frontend, the actual data display has to live in
>> the frontend, and data has to be sent from the backend to the frontend,
>> either as raw numbers, or as some sort of intermediate format like SVG.
>> For that reason, I don't really see something like GtkPlug/GtkSocket as
>> being particularly good fit - it really would work only for a GTK+ (or
>> at least X) based frontand and backend on Linux.
>
> Being able to display interactive widgets is one of the killer features for
> Reinteract for me, so I'd hate to loose that. Some ideas:
> - Have some negotiation of content type. An X frontend could accept a
> GtkPlug/Socket type, while a HTML front end requires a PNG or SVG file.
> - If the Broadway GDK backend is still alive, that might be able to be used
> to embed GTK widgets as HTML in a variety of front-ends.
> - If the backend is willing to act as a webserver, something like the
> matplotlib HTML5 backend (http://code.google.com/p/mplh5canvas/) could be
> used.
> But all of these complicated the model of having a backend that just has to
> worry about executing code.
If we want the interactivity to be able to affect the worksheet, then
things get pretty complex. But if you just want the user to be able to
zoom/rotate/etc. the data, then that doesn't prevent the data being
sent from the backend to the frontend as data... in the case where the
frontend is GTK+, the matplotlib widget would simply live in the
frontend rather than in the backend. You'd have reduced functionality
for the HTML frontend, at least without a lot of effort writing
JS/HTML plotting tools. So, yes, there might be some sort of
negotiation, but I'd still steer away from plug/socket.
- Owen
Owen Taylor
thought for a bit about what I wanted reinteract to be. And generally,
my feeling is that I'm not particularly interested in making Python a
console for Python; I rather want to make it a computing environment
of its own: highly compatible with Python, able to use existing Python
code, but not concerned with broad integration into everything that
one might possibly be doing with Python.
Really, a main limiting factor on reinteract is the "gaps" where the
internal workings show through; where it does something unexpected.
Reinteract is supposed to be accessible to new-comers, and programming
is hard enough without your environment having built-in quirks.
For that reason, I don't really considering interoperating with Jython
and IronPython all that interesting. It's hard to see how a Reinteract
version on those systems; throwing Java or C# libraries into the mix,
wouldn't make things even less robust.
I *am* pretty interested in PyPy, because there's at least the
theoretical possibility of being able to hook into the PyPy
interpreter to do snapshotting and rollback in a more effecient and
robust fashion than Reinteract can do currently.But that's still
pretty blue-sky.
I'm also not all that interested in just having a Qt frontend for the
sake of a Qt frontend. It's conceivable that Qt would provide a better
cross-platform solutions for native frontends than GTK+, and in that
case, it could make sense to use Qt _instead_ of GTK+. (Though there's
a lot of work investigated in the current frontend, and as a past GTK+
maintainer, I'm a lot more comfortable doing deep magic with GTK+ than
with Qt :-) But in addition? The relevant question to me is how
someone would use Reinteract as a computing platform on Linux,
Windows, OS X, iOS, android, remotely over the web, etc.
I hope that doesn't sound like a too negative responsel. I certainly
appreciate the interest, and would see using Reinteract as a way for
students to experiment with and learn how to use a set of computing
tools written in Python as a core part of its mission.
- Owen
pbouda
now, and at the moment it does everything that we need for our
courses. There is also now multiline editing, parallel processing
support, etc. and it's quite easy to use. So Reinteract should not be
just another console for Python, that's right. Btw IPython uses ZeroMQ
for socket communication, maybe this is also an option for Reinteract.
And of course, to remove "gaps" where internals show through is a
minimum requirement. I still think that Reinteract is a very
interesting approach to Python programming (or computing in
general...), so I am still very interested in contributing. A HTML/
Javascript frontend is of course very nice, but I still think that Qt
would add some value as existing widgets (like pyqwt, Orange widgets,
among others) would be easy to integrate. And there is now Qt Quick
which could be used to experiment with different UIs for coding. You
already mentioned the cross-platform support, which covers the whole
list of computing platforms you mention (we are on Android; remote web
only through Chrome's native client, though... that doesn't really
count, I guess :-)).
I am currently playing with Fluxus (http://www.pawfal.org/fluxus/) and
in my opinion it is definitely an experience when you write code in
that environment. It is a lot of fun, at least. To have a backend to
which you can attach different frontends (and if only to be able to
easily experiment with UIs for computing environments) would be great,
in my opinion.
Best,
Peter