Lets say the
python repl takes a long time to start up, is there a way to start it up in the background so I can create an alias and feed it commands like
python-current "command to run".
There is nothing in the python distribution of doing this kind of opening, 'batteries included' not withstanding.
That programs like editors can handle that kind of thing, is because it is quite clear what to do when you open another file: you just open a window/tab on the new file, handled by the same executable.
Implementing something like that yourself is not that difficult, but you have to think about what happens when the first command has not finished yet and the second is scheduled:
- abort the first command
- queue the second command
- run things in parallel (which requires extra startup time unless you have multiple threads waiting for command)
I have notified running pythons to load and execute modules based on files in a directory that were scanned, http request (on a twisted based system) and with zeromq. What is appropriate depends IMHO what else is needed by the system, I always go with that which works and does have the least overhead. Your
python-current would have to do the proper interfacing.
Often this was combined with reloading certain modules (to get the processing for new commands). For that you can use the
import mycommand # test for a command that requires reloading reload(mycommand)
As an aside: especially when using UI code I have found this reloading useful. Python loading of the executable is comparable with Perl (0.002s on my several years old system,
time python -v). Loading the base modules takes about ten times longer (
time python -c "exit();", 0.025s). But when using UI based programs the whole startup easily grows to several seconds and more. And in that case implementing dynamic command reading and having apython-current` makes sense.
If you use
bash you could try coprocesses. Ksh also has coprocesses, I'm not sure if both shells have equivalent function in this area. I've only tried the Ksh version (my employer loves klunk, so we used Ksh) and it worked, but it wasn't easy to have more than a single coprocess.
Google for "ksh coprocess example" or "bash coprocess example" and you will find example code. Work from the examples, as the whole thing isn't super intuitive.