[IPython-User] Getting a clean prompt without Ctrl-C
Mon Jan 16 10:40:40 CST 2012
I was thinking more along the lines of just having an option to switch
Enter and Shift-Enter, so that Enter executes and Shift-Enter enters a
new line. Doing automatic stuff with continuations and so on would be
cool, but more advanced than the basic feature I was referring to
On Mon, Jan 16, 2012 at 12:13 AM, Fernando Perez <email@example.com> wrote:
> On Sun, Jan 15, 2012 at 2:07 PM, Brian Granger <firstname.lastname@example.org> wrote:
>> I am strongly -1 on having anything but shift-enter for code execution
>> in the notebook - even as an option. As Fernando mentioned, it has
>> become the standard for notebook style interfaces and
>> over-configurizing things adds complexity to the code base with little
>>> More seriously, it's not trivial, because the notebook client is in
> I figured that the explanation that this 'feature' would require more
> or less the implementation of a full-blown python compiler in
> But you are right, so to avoid any ambiguity: this is one of those
> decisions for which almost two decades of experience show us that the
> model works extremely well in everyday practice, even when moving back
> and forth between an enter-based terminal and a Ctrl-enter notebook.
> Mathematica has both in a setup that's architecturally more or less
> identical to how ipython works (i.e. a terminal based in-process
> kernel+frontend, and a frontend notebook with out-of-process kernels
> that can be interrupted and restarted). And this execution model does
> really work very well once you get used to it, so as Thomas suggest,
> give it a try.
As I noted somewhere else, aside from being very annoying, Shift-Enter
is unportable: it's impossible to press on any kind of mobile device,
such as iPhones, iPads, and from what I've tried/heard, Android
devices as well.
> The larger point Brian makes about configuration is also very valid:
> we should not make every single last bit of ipython's functionality
> configurable, because every new option also comes with a price in
> added complexity and maintenance requirements. So we need to find a
> balance between sensible defaults and providing configuration only
> when really necessary to cover diverging use cases.
I agree with this. You can leave it as the default if you want, but I
don't see why it shouldn't be configurable.
More information about the IPython-User