Program chaining on Windows

[Rob Cliffe]

On 24/08/2020 00:57, Chris Angelico wrote:
> On Mon, Aug 24, 2020 at 9:51 AM Rob Cliffe via Python-list
> <python-list at python.org> wrote:
>> Let me describe my actual use case.  I am developing a large Python
>> program (in Windows, working in DOS boxes) and I constantly want to
>> modify it and re-run it.  What I have been doing is to make it respond
>> to a hotkey by calling itself via os.system.  The problem is that if I
>> do this 50 times I am left with 51 instances still running, each one
>> waiting for the next to finish.  That's actually OK, except that when I
>> finally shut it down, it takes a long time (about 2.5 sec per instance).
>>
>> I have found a workaround: a small shell program which calls the main
>> program (wth os.system), then when the latter exits, calls it again (if
>> required).  Starting the main program is slightly slower, but acceptably
>> so; shutting it down becomes constant time.
>>
>> But I would still like to be able to do it as I originally planned, if
>> possible.  Not least because I may have other uses for program
>> "chaining" in future.
>>
> Hmm. Python isn't really set up to make this sort of thing easy.
I guess this sentence pretty well answers my whole post. :-(
>   My
> recommendations, in order of priority, would be:
>
> 1) What you're doing, but with a dedicated exit code that means
> "changed, please restart me"
That is pretty much what I am now doing.  I return (to a shell program) 
exit codes which mean "such-and-such a hotkey was hit, please restart me".
>
> 2) The same thing but entirely within Python. Instead of importing
> modules, manually load them and exec the source code. (No relation to
> the process-level exec - I'm talking about the exec function.)
> Updating is way WAY faster, but it isn't the same thing as restarting.
> Your code has to be built with this in mind.
Ah, there's the rub.  This program will be run stand-alone at client 
sites and I need to test it "as is".  As I see it I can't responsibly 
rewrite the way it works (if I'm understanding you more or less correctly).
>
> 3) Similar to #2 but using a language that's designed with that kind
> of thing in mind. Off topic for this list but it's something I've done
> on a number of occasions, so I'd be happy to discuss that with you.
No, no, no, Python is for me!  (Seriously: rewriting in another language 
would be far too time-consuming and *error-prone*.  Not to mention 
unenjoyable.)
>
> 4) Any other option available
>
> 5) Messing with exec on Windows
Which I've been doing, but without success.

Thanks again, Chris.
Rob
>
> ChrisA