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!

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.

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

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.

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.

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 PEP397 loader.

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?

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.

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).

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.

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.

And remember that on the exactly the same computers when I uninstalled python 3.3 and installed python 3.2, everything works flawlessy (because python 3.2 sets .pyw files to open through pythonw.exe).

I can't reproduce this on XP either. I've tried various combinations of 
.py / .pyw, command line, double-click, etc. and I've not had a single 
problem.

Let's hope someone else can suggest something

Well I did fresh install of windows xp and encountered it. On the other pc with xp I tried it is also present. I don't know why I encounter this, I must try more PCs. If you have xp, please try if you can reproduce the issue and post your result here.

Please post, on a machine where the problem is occurring, the contents of the following keys in the registry. What I have shown below is what you should have (allowing for differing locations for Windows):

[HKEY_CLASSES_ROOT\.py]
@="Python.File"

[HKEY_CLASSES_ROOT\.pyc]
@="Python.CompiledFile"

[HKEY_CLASSES_ROOT\.pyo]
@="Python.CompiledFile"

[HKEY_CLASSES_ROOT\.pys]
@="pysFile"

[HKEY_CLASSES_ROOT\.pyw]
@="Python.NoConFile"

[HKEY_CLASSES_ROOT\Python.CompiledFile]
@="Compiled Python File"

[HKEY_CLASSES_ROOT\Python.CompiledFile\DefaultIcon]
@="\"C:\\Windows\\py.exe\",2"

[HKEY_CLASSES_ROOT\Python.CompiledFile\shell]

[HKEY_CLASSES_ROOT\Python.CompiledFile\shell\open]
@="Open"

[HKEY_CLASSES_ROOT\Python.CompiledFile\shell\open\command]
@="\"C:\\Windows\\py.exe\" \"%1\" %*"

[HKEY_CLASSES_ROOT\Python.File]
@="Python File"

[HKEY_CLASSES_ROOT\Python.File\DefaultIcon]
@="\"C:\\Windows\\py.exe\",1"

[HKEY_CLASSES_ROOT\Python.File\shell]

[HKEY_CLASSES_ROOT\Python.File\shell\open]
@="Open"

[HKEY_CLASSES_ROOT\Python.File\shell\open\command]
@="\"C:\\Windows\\py.exe\" \"%1\" %*"

[HKEY_CLASSES_ROOT\Python.NoConFile]
@="Python File (no console)"

[HKEY_CLASSES_ROOT\Python.NoConFile\DefaultIcon]
@="\"C:\\Windows\\py.exe\",1"

[HKEY_CLASSES_ROOT\Python.NoConFile\shell]

[HKEY_CLASSES_ROOT\Python.NoConFile\shell\open]
@="Open"

[HKEY_CLASSES_ROOT\Python.NoConFile\shell\open\command]
@="\"C:\\Windows\\pyw.exe\" \"%1\" %*"

The .pys entry needn't be there - I left it in by mistake.

Differences:

[HKEY_CLASSES_ROOT\Python.CompiledFile\DefaultIcon]
@="F:\Python33\DLLs\pyc.ico"

[HKEY_CLASSES_ROOT\Python.CompiledFile\shell\open]
value not set

[HKEY_CLASSES_ROOT\Python.File\DefaultIcon]
@="F:\Python33\DLLs\py.ico"

[HKEY_CLASSES_ROOT\Python.File\shell\open]
value not set

[HKEY_CLASSES_ROOT\Python.NoConFile\DefaultIcon]
@="F:\Python33\DLLs\py.ico"

[HKEY_CLASSES_ROOT\Python.NoConFile\shell\open]
value not set

I once agained formatted partition and installed brand new windows, installed drivers and SP3, then python 3.3 and the behaviour is still the same.
As for my python installation, I didn't set anything, just clicked through install. And set install for all users.

Also, I tried another XP machine and the bug was there.

Does the error occur with the standalone launcher downloadable from BitBucket? The "value not set" for shell\open is not good.

Well I installed python using standard python 3.3.0.msi from python.org, so maybe there is something wrong with setting registry keys?

I downloaded standalone launcher from bitbucket and the results are the same:

1) command line "pyw.exe app.pyw" no bug
2) I assigned that standalone launcher to open .pyw files (tried .pyw1 also for unique extension) and in both cases when double clicked in explorer the bug existed

Of course, the "py.exe" launcher with console (both standalone and from python 3.3) DOES NOT produce the error even when launching with double click. It's only pyw.exe double click thing.

The problem is that Explorer displays the IDC_APPSTARTING icon when an app launches, until that app does something ui-ish (eg, creating a window, fetching a windows message).  I could reproduce the problem on XP, and pushed a fix for the launcher to https://bitbucket.org/vinay.sajip/pylauncher/commits/639582f0bebbabbf63fe8746986122173e765baf which solves the problem for me.

I'm not sure what the process is for getting that fix into the Python repo - hopefully Vinay knows :)

If anyone would like to test the fix out, I've put a 32bit pyw.exe with the fix at http://starship.python.net/crew/skippy/downloads/pyw.exe

Good catch, Mark!

I'll wait for confirmation that your patched pyw.exe works, then make the changes in the Python repository and also update the standalone launcher.

Mark, you are my hero! I can't believe it got fixed that fast.

I confirm that for me, the fix works. I just replaced pyw.exe in python33 folder and the bug is gone.

Vinay, is there a chance that the fix will be included in 3.3.1?

If not, is there a chance to create a python 3.3 installer with the patched pyw.exe? As I know nothing of python packaging so I have no idea how to do it and it would be very handy for me.

New changeset 5fddaa709d6b by Vinay Sajip in branch '3.3':
Closes #17290: Loading cursor now does not persist when launching GUI scripts.
http://hg.python.org/cpython/rev/5fddaa709d6b

New changeset 0d55fb0217f1 by Vinay Sajip in branch 'default':
Closes #17290: Merged fix from 3.3.
http://hg.python.org/cpython/rev/0d55fb0217f1

Plus, the standalone launcher has already been updated (the version displayed in the installer and the resource version should be 1.0.1.2):

https://bitbucket.org/vinay.sajip/pylauncher/downloads