[IPython-dev] [Bug 215994] Re: We need to add the "complete" method to the Interpreter/Engine/Controller in IPython1

[Barry Wark]

On Fri, Nov 14, 2008 at 1:30 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Sorry about all of this.  When I marked this ticket as "Won't Fix", I
> did so for a very different reason.  The main reason is that our
> ticket system had lots of stale tickets and this was one of them.  In
> some cases I got rid of tickets that were "future work that we all
> know needs to get done eventually."
>
> So here is my intention and thoughts on the issue:
>
> * The complete method *should* be in the backend.

Oh, good! I appologize for abdicating my responsibilities as an
ipython-dev citizen and agreeing to putting things in the frontend. I
really do hope we can get completion into the core/engine and
should've stuck to my guns and pushed for it. Mea culpa.

> * That doesn't prevent a given frontend from trying to implement
> complete in a different, more efficint manner.
> * This ticket is misleading as it will take a huge amount of
> refactoring in the old ipython core to implement this properly.  We
> have *much* more to do that simply add the method.
> * I want our tickets to be specific and detailed.
> * This particular issue probably has 10 other things that need to be done first.
>
> Things like this should probably go into a development blueprint in
> our sphinx docs with notes on everything that needs to happen.  But
> until someone has lots of time to put into the refactoring, I guess I
> would rather have our ticket list be more focused.
>
> Does this make sense?

Absolutely. In my miniscule time to devote to fun development (ipython
is definitely in that category), my priorities are 1) cocoa frontend
2) distributed notification 3) completion. If no one has taken on the
blueprinting task by the time I get to 3 (some time around 2024 at the
current rate), I'll make a start.

Just to continue the discussion, off the top of my head I see two
high-level design issues facing completion triggered by a frontend:
1. GUI toolkits often expect completion options to be returned to the
toolkit and/or displayed synchronously. Getting them via a deferred is
going to be tricky unless we can block until that deferred returns
(with a time out, obviously). I'm pretty sure this is a solved issue
(blocking until a deferred returns), but I know it can get tricky to
get just right.
2. A use case where the frontend is fronting a controller with
multiple engines. The user triggers completion. What options are
returned? Since the engines may have different namespaces, it's
unclear which namespace to use for completion. Will the frontend have
to know which engine will receive the resulting block (i.e. the one
the user is editing)?

Cheers,
Barry

>
> Cheers,
>
> Brian
>
>
> On Fri, Nov 14, 2008 at 9:31 AM, Barry Wark <barrywark at gmail.com> wrote:
>> On Fri, Nov 14, 2008 at 8:44 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
>>> On Thu, Nov 13, 2008 at 7:28 AM, Barry Wark <barrywark at gmail.com> wrote:
>>>
>>>> I agree with the decision to push completion into the frontends.
>>>> However, now we need to think about how the frontend is to gain
>>>> knowlege of the relevant namespace (presumably the user wants the
>>>> completion to be relevant for the namespace where the command will
>>>> eventually be executed, not for the frontend). Observing namespace
>>>
>>> I don't really see the point of doing it in the frontend, since it's
>>> clearly a "model" level feature, and can't be reliably done in
>>> frontend. What about custom completers etc.?
>>
>> Because the engine may be remote, I believe the consensus was that no
>> one wanted to take the chance that there would be no completions
>> available due to network lag or outage.
>>
>>>
>>> --
>>> Ville M. Vainio
>>> http://tinyurl.com/vainio
>>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>