[IPython-dev] ipython on google app engine
barrywark at gmail.com
Wed May 28 02:11:03 EDT 2008
On Tue, May 27, 2008 at 3:14 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> My picture is this (as far as tab completion):
> 1) The frontend has to handle the event (pressing of TAB).
> 2) Upon TAB being pressed, the frontend will dispatch the request to a
> number of different methods. It would first see if it (the frontend)
> could complete it. But that is unlikely as the frontend wont' have
> the user's namespace. If it can't complete it, it will ask the
> backend to do the completion. Even that might fail if the backend is
> busy though.
> But the important point is that for anything that requires
> introspecting the users namespace, the backend has to do that as the
> frontend doesn't have the required info.
One of the things that's come up as I'm (very slowly) working on the
cocoa frontend is that implementing something like Matlab's workspace
(i.e. user namespace) browser requires that the frontend query the
engine for the user namespace keys (and their values) after each
operation that might affect the namespace. So, could the engineservice
provide some hints about what keys in the user namespace were
altered/added/removed as a result of execution of a block? Either way,
if the frontend maintains this (flat) local copy of the user
namespace, than many completions could be accomplished locally.
> so, I guess I would say that both the frontend and backend work
> together to do the tab completion.
> On Sun, May 25, 2008 at 10:49 AM, Barry Wark <barrywark at gmail.com> wrote:
>> On Sat, May 24, 2008 at 1:50 AM, Ondrej Certik <ondrej at certik.cz> wrote:
>>> I'd love to use ipython on the google app engine. Currently our shell
>>> looks like this:
>>> But I just prefer the ipython style. What I use/like on ipython is just:
>>> 1) the look and feel (lines starting with  etc.)
>>> 2) tab completion
>>> 3) ? and ??
>>> 4) inteligent up/down arrows history browsing
>>> and I think that's all (sometimes I use some other features, but very
>>> rarely). So when thinking about it again,
>>> 1) should be easy to fix, or at least come to a very close look & feel,
>>> 2) This will be hard, as it will require an interaction between the
>>> webbrowser and the server. We may learn from Sage, ipython1 or
>> It's my understanding that the current plan is for tab completion to
>> be handled in the frontend, not at the engine level in ipython1.
>> Mapping the ipython1 model directly to this situation, the tab
>> completion would happen in the browser. Since this is a bit
>> impractical, I'd suggest Ville's solution. The nature of the AppEngine
>> will mitigate the risk that the server is slow to respond to the tab
>> completion request (a possiblity in the ipython1 model if the
>> controller or engine handled the completion request).
>>> 3) this should be easy, it will simply copy the command to the server,
>>> and in python we'll parse it and return some help
>>> without it quite well,
>>> Note, that the requirement is that it runs on the google app server.
>>> What do you think? How does this fit into the ipython1 model? I'd like
>>> to have something now, but also I'd prefer to work on one thing
>>> ipython1, instead of doing things on my own. Also I probably won't
>>> have much time either. But my motivation to run something like
>>> ipython+sympy on google app engine is also big. :)
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>> IPython-dev mailing list
>> IPython-dev at scipy.org
More information about the IPython-dev