Eric Schulte <schulte.eric <at> gmail.com> writes:
> You are suggesting that code to be run "interactively" should be written
> to an external file then loaded into the interactive session.
Generally, yes, because babel's definition of "interactive" (execute an
arbitrary collection of code lines all at once) is different from an interactive
shell session's (execute a single statement of statement block at a time, giving
output after each).
> This
> would certainly work around the syntax limitation of the current setup.
> My two concerns here are that
>
> 1. users who use interactive babel blocks side-by-side with the session
> may be used jumping into the session to play with code interactively
> and debug, in such cases rather than seeing their code in the session
> history they would only see execfile('/tmp/blahblah'). Note I do
> recall discussion on list related to user's reading their session
> code in the inferior session buffer.
I see your point, that's a valuable tool. Ideally, it seems to me, the session
blocks could be evaluated _either_ "interactively" (with a history in shell
session) or as a block-as-a-whole. Having a named session (e.g., ':session
debug') designated to use the interactive mode and other :sessions use
"non-interactive" mode would be one way to do this.
> 2. similarly error messages would now point into this temporary file,
> rather than back into the session history
I think the ':session debug' behavior in paragraph above could get around this.
(I think there are also ways to feed the source lines through <stdin> but that
doesn't get around your issue 2., anyway.)
>
> Basically you would prefer more decoupling from the interpreter and I'm
> not sure for the average user if this would be a worthwhile exchange
> simply to be able to avoid syntax errors like your originally mentioned
> example (which was the first such post I've seen on this list).
>
> I'm disinclined to make such a change without a wider base of support
> for the request from the Babel/Python user community -- or at least
> without more complaints about the existing behavior.
>
Yeah, I completely get you here. If there are no other complaints about
existing behavior, and with limited resources, there's no good reason to change
things.
Regards,
Herb
