os.startfile hanging onto the launched app, or my IDE?

[Josh English]

I have been using os.startfile(filepath) to launch files I've created in Python, mostly Excel spreadsheets, text files, or PDFs.

When I run my script from my IDE, the file opens as I expect. But if I go back to my script and re-run it, the external program (either Excel, Notepad, or Acrobat Reader) closes all windows and restarts the program. This can,unfortunately, close other files I am working on and thus I lose all my changes to those files.

This is happening on Windows 7.

I am not sure if it is Python (2.7.5) or my IDE (PyScripter 2.5.3).

It seems like Python or the IDE is keeping track of things created by the os.startfile call, but the docs imply this doesn't happen.

Is this a quirk of os.startfile? Is there a cleaner way to get Windows to open files without tying back to my program?

Thanks,

Josh

 

[Tim Golden]

I have been using os.startfile(filepath) to launch files I've created
in Python, mostly Excel spreadsheets, text files, or PDFs.

When I run my script from my IDE, the file opens as I expect. But if
I go back to my script and re-run it, the external program (either
Excel, Notepad, or Acrobat Reader) closes all windows and restarts
the program. This can, unfortunately, close other files I am working
on and thus I lose all my changes to those files.

This is happening on Windows 7.

I am not sure if it is Python (2.7.5) or my IDE (PyScripter 2.5.3).

It seems like Python or the IDE is keeping track of things created by
the os.startfile call, but the docs imply this doesn't happen.

Is this a quirk of os.startfile? Is there a cleaner way to get
Windows to open files without tying back to my program?

I'm not 100% sure what your scenario is, but you can certainly help
yourself and us by running the same test on the raw interpreter and then
under PyScripter to determine if the behaviour is to do with IDLE or
with Python itself.

My half-guess is that PyScripter starts a new process to run your code,
possibly killing any pre-existing process first. That's if I've
understood the situation you're describing.

Could you come back with a little more detail? Specifically: whether
what you're seeing happens only from within PyScripter, or only not from
within PyScripter, or something else?

TJG

 

[Ian Kelly]

I have been using os.startfile(filepath) to launch files I've created in Python, mostly Excel spreadsheets, text files, or PDFs.

When I run my script from my IDE, the file opens as I expect. But if I goback to my script and re-run it, the external program (either Excel, Notepad, or Acrobat Reader) closes all windows and restarts the program. This can, unfortunately, close other files I am working on and thus I lose all my changes to those files.

This is happening on Windows 7.

I am not sure if it is Python (2.7.5) or my IDE (PyScripter 2.5.3).

It seems like Python or the IDE is keeping track of things created by theos.startfile call, but the docs imply this doesn't happen.

Is this a quirk of os.startfile? Is there a cleaner way to get Windows toopen files without tying back to my program?

That sounds unusual. Do you see the same behavior with the shell
"start" command? My first guess would be that this is due to some
registry setting rather than Python, which pretty much just calls
ShellExcecute.

 

[Josh English]

I'm not 100% sure what your scenario is, but you can certainly help
yourself and us by running the same test on the raw interpreter and then
under PyScripter to determine if the behaviour is to do with IDLE or
with Python itself.

My half-guess is that PyScripter starts a new process to run your code,
possibly killing any pre-existing process first. That's if I've
understood the situation you're describing.


Could you come back with a little more detail? Specifically: whether
what you're seeing happens only from within PyScripter, or only not from
within PyScripter, or something else?

I think you're right about PyScripter controlling the process. I don't run scripts through the command line as a matter of practice.

But I just tried running my script through the command line, with Excel closed, and it opened the Excel file just as I expected. Then I went back to the command line and ran it again, and it didn't close Excel. It gave me theerror I was expecting from zipfile not being able to access the file (because it is currently open).

I even left it open and ran another script that also creates and launches an Excel workbook, and it again did not close Excel.

So this quirk is coming from PyScripter, which is a shame, because I don't think it's under development, so it won't be fixed.

Josh

 

[Ethan Furman]

So this quirk is coming from PyScripter, which is a shame, because I don't think it's under development, so it won't be fixed.

The nice thing about Python code is you can at least fix your copy.

 

[Tim Golden]

The nice thing about Python code is you can at least fix your copy.

IIRC, PyScripter is actually written in Delphi!

TJG

 

[Ethan Furman]

IIRC, PyScripter is actually written in Delphi!

Ah, well, in that case forget I spoke. :/