[IPython-dev] Prompt manager
Wed Sep 14 15:29:11 CDT 2011
On Sat, Sep 10, 2011 at 12:42 PM, Fernando Perez <email@example.com> wrote:
> On Sat, Sep 3, 2011 at 5:53 AM, Thomas Kluyver <firstname.lastname@example.org> wrote:
>> First, for generating prompts over ZMQ, we intended to use the
>> user_expressions field of an execution request, but this can't easily access
>> things that aren't in the user namespace, e.g. os.getcwd(). We can work
>> round that using the __import__("os").getcwd() form, but it feels somewhat
>> less than ideal. This can however be resolved at a later stage, because the
>> frontends currently generate prompts by themselves - my primary aim with
>> this is to simplify the rather convoluted code generating prompts for the
>> plain terminal.
> I've been thinking a fair bit about this issue, and I think we need to
> introduce an extra namespace, let's call it frontend_ns, that
> frontends can use to execute their code in, keep variables available
> without collisions with the user, etc. Then, things like prompt
> computations and similar could be done there.
> Granted, if multiple frontends are connected they'd be sharing this
> namespace, but at least it would be isolated from the user one. I
> think this would give us a lot of flexibility for interactions with
> the frontends. The need for an isolated space to manage prompts is
> what got me thinking along these lines, but I could imagine frontends
> keeping richer state and exposing a highly customized view to the user
> in a notebook, with an 'app' view, and then allowing them to further
> execute code in their own user_ns that only sees the data the app
> wants to expose.
I think this sounds like too much additional complexity for something
that very few users ever touch.
Every new feature we add is something we have to maintain, test,
debug, etc. Also, in the notebook, we have to size the prompt area
statically, so I don't think it makes sense to even allow prompt
customization in that context. I *do* think that we should provide
increasingly powerful and rich ways of displaying and interacting with
data in the output area, but I don't think user data should start to
creep into other parts of the UI. I am -1 on this.
> IPython-dev mailing list
Brian E. Granger
Cal Poly State University, San Luis Obispo
email@example.com and firstname.lastname@example.org
More information about the IPython-dev