pythonw - loading cursor bug when launching scripts

[netrick]

BPO	17290
Nosy	@loewis, @mhammond, @terryjreedy, @vsajip, @tjguk, @briancurtin
Files	AZb4toA.jpg: this is how the cursor looks like for the first 15 secs

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-02-26.16:29:59.060>
created_at = <Date 2013-02-24.21:34:32.252>
labels = ['expert-tkinter', 'type-bug', 'expert-installation', 'OS-windows']
title = 'pythonw - loading cursor bug when launching scripts'
updated_at = <Date 2013-02-26.16:33:18.038>
user = 'https://bugs.python.org/netrick'

bugs.python.org fields:

activity = <Date 2013-02-26.16:33:18.038>
actor = 'vinay.sajip'
assignee = 'none'
closed = True
closed_date = <Date 2013-02-26.16:29:59.060>
closer = 'python-dev'
components = ['Installation', 'Tkinter', 'Windows']
creation = <Date 2013-02-24.21:34:32.252>
creator = 'netrick'
dependencies = []
files = ['29224']
hgrepos = []
issue_num = 17290
keywords = []
message_count = 27.0
messages = ['182895', '182905', '182939', '182941', '182945', '182948', '182949', '182951', '182953', '182956', '182957', '182958', '182965', '182971', '182974', '182975', '182977', '182985', '182987', '182988', '183005', '183006', '183008', '183063', '183065', '183066', '183067']
nosy_count = 9.0
nosy_names = ['loewis', 'mhammond', 'terry.reedy', 'vinay.sajip', 'tim.golden', 'brian.curtin', 'python-dev', 'Ramchandra Apte', 'netrick']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue17290'
versions = ['Python 3.3']

[netrick]

Firstly, just to mention - the issue that I will describe doesn't exist in python 2.7. It is python3 and windows related (python 3.3 for sure, didn't test previous). I also tested it on 2 different PCs (one fresh windows install, second long running with different hardware), so it's not my OS messed up.

So - the issue appears with every gui script I tried (PySide and tkinter, various codes). Basically when I have the script saved as "*.py", everything is great but there is unwanted console. So I save the script as "*.pyw" to run it using "pythonw" without console. When I run it there is indeed no console, but for the first 10-15 seconds no matter what I do the cursor is "loading cursor", everywhere in Windows. (see the screen I uploaded to this issue). I can click everything but the cursor won't return to normal for about 15 secs. Of course, the cursor is normal when using standard python 3.3 (with console) or pythonw 2.7.

The code pasted from 3.3 documentation which reproduces the problem:

#START CODE
import tkinter as tk

class Application(tk.Frame):
 def __init__(self, master=None):
 tk.Frame.__init__(self, master)
 self.pack()
 self.createWidgets()

 def createWidgets(self):
 self.hi_there = tk.Button(self)
 self.hi_there["text"] = "Hello World\n(click me)"
 self.hi_there["command"] = self.say_hi
 self.hi_there.pack(side="top")

 self.QUIT = tk.Button(self, text="QUIT", fg="red",
 command=root.destroy)
 self.QUIT.pack(side="bottom")

 def say_hi(self):
 print("hi there, everyone!")

root = tk.Tk()
app = Application(master=root)
app.mainloop()
#END CODE

To sum up, the issue is present with pythonw 3.3 on Windows XP 32 bit.
BUT! When I typed in terminal:

ftype Python.File=C:\Python33\pythonw.exe "%1" %*

then every .py file started to be run using pythonw. What matters is in that case, there is no loading cursor at all! Add to it that in python 2.7 the issue doesn't exist and I think that in recent windows packages something with extensions is messed up. I have no idea what, but this stops me from using python3 for serious GUI development on windows (which is something I really want to do).

I wanted to write some commercial GUI apps using python, but I can't say my customers to type that line in terminal. Also, they won't accept terminal or 15 sec loading cursor. It's just unwanted thing. Right now I have to use python 2.7, but I like python 3 much more. I think it's something with the way ".pyw" extension is handled as something adds that loading cursor.

Python is the best, I hope that you will be able to fix it!

[netrick]

I just want to add that it *may* be the issue with the new windows launcher introtuced in 3.3. Because in 2.7 everything runs great and running through "pythonw" command works flawlessy as well. I think it's worth to look into it.

[RamchandraApte]

Advice: anything that's not a photo should be PNG.
Temporary fix is to change the cursor see [0]
^0 http://effbot.org/zone/tkinter-busy.htm

[netrick]

Well actually it IS a photo, so I think it can remain .jpg (because on print screen there is no cursor). Thanks for the temporary solution, altough I'm not sure if pyside/pygame etc will allow me to change busy cursor too.

Is there any chance for this to be fully fixed? It is a regression as it isn't present in previous releases, my bet is new windows launcher which does some work in the background.

[netrick]

The issue is NOT present in python 3.2. I'm not expert, but given that it work in 3.2 and works in 3.3 using direct "pythonw" command, I'm almost sure it's new windows launcher. Even if I'm wrong, you guys can be sure that the issue appeared in 3.3 so there are only few possibilities.

[tjguk]

I can't reproduce this running Python 3.3 on Win7. I'll try WinXP later.
I'll also add Mark Hammond & Vinay as they implemented the PEP-397 loader.

[tjguk]

netrick: can you confirm that the same thing occurs when you explicitly
run your code via the pyw command. ie when you do this:

pyw myprog.pyw

Also, what happens when you run:

py myprog.pyw

ie when you use the Console launcher to launch the .pyw?

[netrick]

My OS is Windows XP so it may be only XP related. So, python 3.3 and my testing:

1. pythonw app.pyw - no bug
2. python app.pyw - no bug
3. pyw app.pyw - no bug
4. py app.pyw - no bug
5. double click on app.pyw - BUG

Tested on 2 different computers with exactly the same results. Both windows xp. Now I'm a little bit lost as running directly "pyw app.pyw" doesn't cause the bug.

However I read that the launcher assigns .pyw files in windows to some .bat script instead of pure pyw.exe. How can we check it? We need to dig into what exactly is started when .pyw script is run through double click.

[tjguk]

Things may be a little more complicated, because one of two distinct
mechanisms may be invoked to determine what to run when double-clicking:
an Explorer-based mechanism, and a non-Explorer one.
AFAICT, the former falls back to the latter.

To check the latter, the command-line you used earlier:

assoc .pyw # -> Python.NoConFile

ftype Python.NoConFile # -> whatever path

To check the former, there's a registry key which escapes me at
the moment but wouldn't be too hard to find. Obviously there's
no reason why either should cause a delay, unless you've previously
done something obscure like associate .pyw files with a network-based
copy of Python or something.

To see the non-Explorer association in action, open a command
shell in the appropriate directory, and just start the program
with: app.pyw (ie without specifying a program).

[netrick]

So:

1. "assoc .pyw # -> Python.NoConFile" gives an error that it can't find association for .pyw extension
2. opening terminal in proper directory and typing just "app.pyw" gives error that this is not known command

I did small test. Using normal (from explorer) "open with + always use this program to open this file", firstly I associated .pyw to pythonw.exe - there is no bug when double clicking.

Then, I changed it to "pyw.exe" and the bug reappeared when double clicking.

[netrick]

I can use assoc command for .py extension but I can't for .pyw. Maybe that's some clue...

The strange thing is that explicit "pyw.exe app.pyw" gives no bug, and associating .pyw files to "pyw.exe" gives the bug when double clicking. Honestly I have no idea what's going on.