[IPython-dev] Prompt manager
fperez.net at gmail.com
Wed Sep 14 19:18:21 EDT 2011
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...
More information about the IPython-dev