[IPython-dev] Prompt manager
ellisonbg at gmail.com
Thu Sep 15 18:56:01 EDT 2011
On Wed, Sep 14, 2011 at 4:18 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> 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.
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 at calpoly.edu and ellisonbg at gmail.com
More information about the IPython-dev