Installing Python 3, without using it, makes Windows shortcuts run multiple instances of apps

wxPython Users
1

I’ve been using Python 2.7 and wxPython 2.8 for many years and today I started work on migrating to recent versions of these programs. I began by installing Python 3.6 and, to get my old wxPython apps working, I added to each of them as the first line “#! /usr/bin/python2.7”. My apps now all work correctly, except for one annoying little problem.

My OS is Windows 10 and I have Windows shortcuts to access my applications, e.g., “ctrl-alt-o” is the shortcut for one app. Previously, if the relevant application was already open, pressing the shortcut keys would bring it to the foreground and give it the focus. But now, what happens is that a new instance of the application opens. I haven’t changed anything except to install Python 3 and add that shebang line. Can somebody tell me what’s caused this change and, ideally, if there’s a way to revert to the previous behavior (only one instance of the application runs)?

I searched the web for an answer to this question but all that I found was people talking about sophisticated programming strategies to run only a single instance. I think the solution to my problem should be simpler than that, since things previously worked the way I wanted them to and I haven’t changed the apps, other than to add the shebang line so they use Python 2.7.

Patrick

2

I should have said that in my Windows shortcuts, the target is the relevant .pyw file, e.g., “C:…\play.pyw” and it starts in the directory containing this file.

Patrick

3

I don't use MS Windows but I think it might be that your installation of
python 3.6 may have changed the file associations so from the shortcut it
launches using 3.6 and ignores the shebang but when you launch it directly
it accepts the shebang.

···

--
Sent from: http://wxpython-users.1045709.n5.nabble.com/

4

I've been using Python 2.7 and wxPython 2.8 for many years and today I
started work on migrating to recent versions of these programs. I began by
installing Python 3.6 and, to get my old wxPython apps working, I added to
each of them as the first line "#! /usr/bin/python2.7". My apps now all
work correctly, except for one annoying little problem.

My OS is Windows 10 and I have Windows shortcuts to access my
applications, e.g., "ctrl-alt-o" is the shortcut for one app. Previously,
if the relevant application was already open, pressing the shortcut keys
would bring it to the foreground and give it the focus. But now, what
happens is that a new instance of the application opens. I haven't changed
anything except to install Python 3 and add that shebang line. Can somebody
tell me what's caused this change and, ideally, if there's a way to revert
to the previous behavior (only one instance of the application runs)?

I think (though I speak under correction) that what's happening is that

you've broken Windows' mechanism for determining whether the app is still
running or not. When you double-click the icon, or press the shortcut
keys, Windows uses the system default app to open that item - in your case,
the Python 3.6 binary. Windows notes the resulting process ID; if, the
next time you use the shortcut, that ID is still active, then Windows
simply brings it forward.
But the shebang line tells Python 3.6 "You're not my real dad! Go find
Python 2.7 and launch me with that binary, and then go kill yourself!"
(Well, there's a lot less family drama, but you get the picture.) The
original process ID goes away, and your app is running under a different
ID, which Windows knows not.
Remember: from your perspective, what's running is your own program. From
Windows' perspective, what's running is the Python binary, which just
happens to be executing your instructions. If you change binaries, you
change processes.

I searched the web for an answer to this question but all that I found was
people talking about sophisticated programming strategies to run only a
single instance. I think the solution to my problem should be simpler than
that, since things previously worked the way I wanted them to and I haven't
changed the apps, other than to add the shebang line so they use Python 2.7.

If, instead of the shebang line, you modify the shortcut's command line to

open your script with the Python 2.7 binary instead of the system default,
I _think_ you'll get back to your desired behavior. Let us know.

···

On Thu, Jun 21, 2018 at 12:20 PM, Patrick Maher <patrick@maher1.net> wrote:

5

Thanks a lot, Marc. I changed the target in the shortcut from “C…\play.pyw” to “C:\Python27\pythonw.exe play.pyw” and now I no longer get multiple instances. Bravo! – Patrick

6

Excellent! I was 99% sure, but not 100%. Thanks for the update!

···

On Thu, Jun 21, 2018 at 7:22 PM, Patrick Maher <patrick@maher1.net> wrote:

Thanks a lot, Marc. I changed the target in the shortcut from
"C\...\play.pyw" to "C:\Python27\pythonw.exe play.pyw" and now I no longer
get multiple instances. Bravo! -- Patrick

7

Actually, Marc, you were 99.5% correct. The python executable does _not_
honour the shebang line. Instead the default behaviour, (IIRC - I know
it is selectable but depends if you select "Make this the default
python"), of the Python 3.6 installer is to change the association of
*.py files to C:\Windows\py.exe and of *.pyw files to C:\Windows\pyw.exe
which are the python launcher programs.

The py[w].exe launchers find the available python installations on your
machine and examine the file that is trying to be invoked (from the
command line or short cut) for the shebang line. If one is found it is
attempted to honoured with the highest found python revision (assuming
that you have multiple python installations) and if one is not found it
will use a rule based system.

As an example lets assume that we have python 2.7 32 bit, 3.5 64 bit and
3.6 both 32 and 64 bit.

Shebang Python
#! /usr/bin/python2.7 2.7 (32)
#! /usr/bin/python2.7-64 Error: Requested Python version (3.4) is
not installed
#! /usr/bin/python3 3.6 (64)

#! /usr/bin/python2.7 2.7 (32)
#! /usr/bin/python3.5 3.5 (64)
#! /usr/bin/python3.4 Error: Requested Python version (3.4) is
not installed
#! /usr/bin/python3 3.6 (64)
#! /usr/bin/python3.5 3.5 (64)
#! /usr/bin/python3-32 3.6 (32)

<No shebang> 3.6 (64)

Then you are quite correct the python launcher invokes the appropriate
python with the arguments that have been given - and this is what is
confusing Windows.

It might be worth raising a ticket (or seeing if one already exists) on
the python launcher if it is felt that this behaviour is too
undesirable. (I am not sure when/if anybody will have the time to get
around to it when there is such a simple work around and this only
impacts people using short cut keys who are not using the wx Single
Instance checker instead).

···

On 22/06/2018 05:26, Marc Tompkins wrote:

On Thu, Jun 21, 2018 at 7:22 PM, Patrick Maher <patrick@maher1.net > <mailto:patrick@maher1.net>> wrote:

    Thanks a lot, Marc. I changed the target in the shortcut from
    "C\...\play.pyw" to "C:\Python27\pythonw.exe play.pyw" and now I no
    longer get multiple instances. Bravo! -- Patrick

Excellent! I was 99% sure, but not 100%. Thanks for the update!

--
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.

---
This email has been checked for viruses by AVG.