Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #72883 > unrolled thread

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

Back to article view | Back to comp.lang.python

Contents

  os.startfile hanging onto the launched app, or my IDE? Josh English <Joshua.R.English@gmail.com> - 2014-06-06 13:34 -0700
    Re: os.startfile hanging onto the launched app, or my IDE? Tim Golden <mail@timgolden.me.uk> - 2014-06-07 21:24 +0100
      Re: os.startfile hanging onto the launched app, or my IDE? Josh English <Joshua.R.English@gmail.com> - 2014-06-09 15:21 -0700
        Re: os.startfile hanging onto the launched app, or my IDE? Ethan Furman <ethan@stoneleaf.us> - 2014-06-09 15:31 -0700
        Re: os.startfile hanging onto the launched app, or my IDE? Tim Golden <mail@timgolden.me.uk> - 2014-06-10 05:46 +0100
        Re: os.startfile hanging onto the launched app, or my IDE? Ethan Furman <ethan@stoneleaf.us> - 2014-06-10 13:45 -0700
    Re: os.startfile hanging onto the launched app, or my IDE? Ian Kelly <ian.g.kelly@gmail.com> - 2014-06-08 11:56 -0600

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

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

[toc] | [next] | [standalone]

#72929

On 06/06/2014 21:34, Josh English wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#73062

On Saturday, June 7, 2014 1:24:43 PM UTC-7, Tim Golden wrote:
>
> 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 the error 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

[toc] | [prev] | [next] | [standalone]

#73063

On 06/09/2014 03:21 PM, Josh English wrote:
>
> 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.  :)

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#73070

On 09/06/2014 23:31, Ethan Furman wrote:
> On 06/09/2014 03:21 PM, Josh English wrote:
>>
>> 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.  :)

IIRC, PyScripter is actually written in Delphi!

TJG

[toc] | [prev] | [next] | [standalone]

#73127

On 06/09/2014 09:46 PM, Tim Golden wrote:
> On 09/06/2014 23:31, Ethan Furman wrote:
>> On 06/09/2014 03:21 PM, Josh English wrote:
>>>
>>> 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.  :)
>
> IIRC, PyScripter is actually written in Delphi!

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

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#72984

On Fri, Jun 6, 2014 at 2:34 PM, Josh English <Joshua.R.English@gmail.com> wrote:
> 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?

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web