What you suggest is exactly what we do currently. The downside is that we
need to implement parsers for each language and put another proxy in front
of the kernels or kernel gateway and ensure that our parsers are using the
same underlying runtime as the kernel if they parse a proper AST. So the
advantage of having a feature like this would be that kernels could
implement this behavior directly, against the same runtime, and everybody
could share this implementation easily across both commands like jupyter
run and kernel gateway.
They very real downside, which you allude to, is there are many approaches
to chunking a file. For instance, one might want to use something like Rmd
or allow some output control in comment pragmas. This could be
accommodated by having a style parameter.
On Thu, Oct 13, 2016 at 5:52 AM, MinRK <benjami...@gmail.com> wrote:
> I don't believe any protocol changes are needed for this. You can already
> run a script through Jupyter, breaking it up however you want. The trick
> would be writing a runner for a given script (you would need to write a
> different one for every language to do the parsing correctly), and then
> submit the chunks as you see fit. Alternatively, you could rely on simple
> markers in comments to identify the chunks to split on.
> There is [a PR](https://github.com/jupyter/jupyter_client/pull/184)
> adding a `jupyter run` command that executes a script as a whole file. It
> doesn't record the output into a notebook, but a similar script that does
> would not be a large project.
> What do you see as a needed change to the protocol that isn't served by
> what we already have?
> On Thu, Oct 13, 2016 at 9:57 AM, Tristan Zajonc <trist...@gmail.com>
>> Has anybody considered extending the jupyter messaging protocol to allow
>> kernels to optionally implement statement-by-statement execution? This
>> would allow users to create notebooks from raw scripts, akin to RStudio.
>> The behavior of the parser would be up to the kernel, but typically it
>> would parse a code string into statements that could be executed
>> I'd be interested in potentially adding this feature -- I've done so
>> out-of-band for R and Python -- but am curious if there's a preferred
>> path. I could imagine either extending execute_request to take a "split"
>> parameter, although that may get confusing since there would then be
>> multiple execute_results. The alternative would be to implement a new
>> message type, execute_statements, then would parse the code string and
>> issue multiple execute_requests. This should be backward compatible since
>> the output messages would be unchanged.
>> This could be combined with something like: jupyter notebook run
>> analysis.py --output=results.ipynb
>> Is this worth pursuing as part of an enhancement proposal?
>> You received this message because you are subscribed to the Google Groups
>> "Project Jupyter" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jupyter+unsubscr...@googlegroups.com.
>> To post to this group, send email to email@example.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> For more options, visit https://groups.google.com/d/optout.
> You received this message because you are subscribed to a topic in the
> Google Groups "Project Jupyter" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> To unsubscribe from this group and all its topics, send an email to
> To post to this group, send email to firstname.lastname@example.org.
> To view this discussion on the web visit https://groups.google.com/d/
> For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups
"Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.