[IPython-dev] Prompt manager
Thu Sep 15 17:56:01 CDT 2011
On Wed, Sep 14, 2011 at 4:18 PM, Fernando Perez <email@example.com> wrote:
> On Wed, Sep 14, 2011 at 1:29 PM, Brian Granger <firstname.lastname@example.org> 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
email@example.com and firstname.lastname@example.org
More information about the IPython-dev