[IPython-User] Getting a clean prompt without Ctrl-C

Aaron Meurer asmeurer@gmail....
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
here.

On Mon, Jan 16, 2012 at 12:13 AM, Fernando Perez <fperez.net@gmail.com> wrote:
> On Sun, Jan 15, 2012 at 2:07 PM, Brian Granger <ellisonbg@gmail.com> 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
>> benefit.
>>
>>> More seriously, it's not trivial, because the notebook client is in
>>> javascript and not python.
>
> [...]
>
> I figured that the explanation that this 'feature' would require more
> or less the implementation of a full-blown python compiler in
> javascript would kind of nip it in the bud :)
>
> 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.
>
> Cheers,
>
> f

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.

Aaron Meurer


More information about the IPython-User mailing list