[IPython-dev] Help! TR: TR: Ipython plugin
Tue Jun 3 13:57:03 CDT 2008
Another thing that we will have to move away from is having a Shell
that talks to the GUI/frontend through callbacks that the frontend
registers. The reason is that the frontend could possibly be in a
completely different process, or even a web browser. In that type of
setting, it is simply impossible for the Shell to call methods in the
frontend. Furthermore, it is too tight of a coupling to have in a
distributed system - what happens if the frontend goes away but the
Instead, all the methods of the Shell will have to return Python
objects (dicts, etcs) that contain the information that the frontend
can use for its own purposes.
On Mon, Jun 2, 2008 at 3:39 PM, Ville M. Vainio <firstname.lastname@example.org> wrote:
> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
> <email@example.com> wrote:
>> I mean we can stay with pyreadline for console based terminal but I think we
>> need something simpler for "graphical" gui.
> I agree. However, this can be done as it is now in iplib.py
> "interact_with_readline" method (which, admittedly, is not excercised
> in current code but mostly server as proof that ipython can be easily
> decoupled from raw_input.
>> (Another time, this is my point of view, some other devs will say that this
>> is the job of a readline object: I'm not ok with that because I want to be
>> free and I need something flexible. "Keep it simple" philosophy)
> I agree with you here. All the direct references to readline should
> factored out of the logic-running classes.
>> - Completer API.
>> Sometihng like:
>> IP.Completer.getCompletion(user_input_to_complete) -> return a list of
>> completion :
> This should be easy. test_completer.py introduces how to "hack" your
> way aroud the lack of API (so far).
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> IPython-dev mailing list
More information about the IPython-dev