[IPython-dev] Prompt manager

Brian Granger ellisonbg@gmail....
Thu Sep 15 17:56:01 CDT 2011

On Wed, Sep 14, 2011 at 4:18 PM, Fernando Perez <fperez.net@gmail.com> wrote:
> On Wed, Sep 14, 2011 at 1:29 PM, Brian Granger <ellisonbg@gmail.com> wrote:
>> I think this sounds like too much additional complexity for something
>> that very few users ever touch.
> Well, the only complexity is really an optional field in the execute
> message, that's all.  And it gives a clean mechanism for other
> frontends (not necessarily ones we maintain) to manage state in a
> robust way that doesn't mess with the user data.  So in many ways it's
> a cleaner solution than what people are already doing with prompts,
> which requires them to work in the same user namespace and hope there
> are no collisions.

Keep in mind that originally, I was 50/50 on adding user_variables and
user_expressions to the execute message.  The reason is that execute
itself is a simple atomic operation.  Adding these other things opens
the door for secondary effects.  I have gotten used to them being
there and I think that they will get some usage for things like a
namespace browser in the notebook.  But, I do think there is a cost to
having them there.

> Basically I'm proposing a way to help people do what they are *already
> doing* in a cleaner fashion, and in a way that adds extremely minimal
> complexity: one more dict to keep around, one more flag in that
> message.  We don't even need a new message type for this.

When users execute code in the other namespace would they have any
access to the global user_ns?  I would think that in most cases they
would *want* that.  IOW, are they completely isolated namespaces or is
frontend_ns used as local() and user_ns as globals()?

>> 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.
> Nobody said the notebook would need to concern itself with the
> prompts, we definitely agree that not all frontends will allow/honor
> prompt customization.  All this does is allow frontends to do certain
> things without stepping on the user namespace.  Currently they are
> doing it by sneaking around with silent=True, which is arguably a much
> worse and more dangerous solution, as it's prone to collisions and
> other problems caused by interference with user actions.

I agree that silent is not a very robust way of handling these things.

> I do think the frontend_ns *is* a simple, good solution to an existing
> problem.  We discussed it with @minrk over lunch and he also seemed to
> be in agreement.  Think about it...

I am still not thrilled, but I am fine being out voted on this.  But I
do think it makes sense to think more about exactly how it would work.



Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com

More information about the IPython-dev mailing list