[IPython-dev] Prompt manager

[Fernando Perez]

On Wed, Sep 14, 2011 at 1:29 PM, Brian Granger <ellisonbg at 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.

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.

> 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 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...