Hi, Tim, Let's say in your example that we are executing Python cells with the same session. When you execute block 1, the routines in org-babel-execute-src-block process the code into something that can be inserted into a file (say 'tmp_code.py') and be run from the command line with python3 tmp_code.py.
At this point, Babel calls org-babel-execute:python, which decides, based on the 'session' header, whether or not to call python3 tmp_code.py or to feed each line in tmp_code.py into the session interpreter. What I am wondering is if we could replace the code for the latter option (in ob-comint.el) by just sending the interpreter the command 'exec(open("tmp_code.py").read())'. Now you can still run block 2 or 3, or block 2 twice, or neither. I think this would simplify a lot of the comint code. All we would need to do is change how we implement the 'exec(open...' code in other languages, for instance, I believe in julia this could be done by an 'include'. Best, Guacho Sent with Proton Mail secure email. ------- Original Message ------- On Thursday, June 23rd, 2022 at 7:53 PM, Tim Cross <theophil...@gmail.com> wrote: > Ivar Fredholm freddyho...@protonmail.com writes: > > > I have been browsing the orgmode code and it feels like we have to do a lot > > to implement sessions. At least for Python > > or Julia, I am wondering if we could instantiate an interpreter, and send > > the code as a single 'exec' or 'include' > > command. Other languages like R and groovy also have facilities to run code > > from a file. I believe this would reduce the > > amount of code needing maintenance, as we would only need to manipulate the > > string to pass to the interpreter based > > on the language. If this has been considered before, could someone explain > > why this approach was not used? > > Best, Guacho > > > I agree that supporting session can be complex, especially with some > languages. The big limitation I can see with your suggestion (assuming I > understand what your proposing) is that you may not necessarily want to > execute all the blocks at once or only execute a block once. > > For example, I might have an org file with 4 code blocks which I want to > all run in the same session. However, I might want to execute each block > interactively, not run all four blocks sequentially all in one batch. I > might execute block 1, then based on the result/output form that block, > execute block 2 or 3, but maybe not both or perhaps I will execute block > 2 twice before executing block 3 etc. > > If you adopt your approach, we would loose that flexibility. The session > argument would essentially boil down to execute all code blocks in this > file within the same batch rather than execute each one in a separate > environment/instance. While this could be a valid interpretation of > session, we would need to be sure it was one which all users found > agreeable. It is possible, for stability and maintainability, a new > definition of session would be acceptable, but it is a change with > implications that would need to be managed carefully.