[Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

[Steve Dower]

> From: Nick Coghlan [mailto:ncoghlan at gmail.com]
> Sent: Friday, May 3, 2013 2348
>
> We don't need examples of arbitrary data file extentions, we need examples
> of 4 letter extensions that are known to work correctly when placed on
> PATHEXT, including when called from PowerShell. In the absence of
> confirmation that 4-letter extensions work reliably in such cases, it seems
> wise to abbreviate the Windows GUI application extension as .pzw.
> 
> I've also cc'ed Steve Dower, since investigation of this kind of Windows
> behavioural question is one of the things he offered distuils-sig help with
> after PyCon US :)

Thanks, Nick. I've been following along with this but haven't really been able to add anything.

I can certainly say that I've never had any issue with more than 3 letters in an extension, and I deal with those every day (.pyproj, .csproj, .vxcproj.filters, etc).

The PowerShell bug (which I hadn't heard of before) may be a complete non-issue, depending on how the associations are set up.

To summarise the bug, when PowerShell invokes a command based on an extension in PATHEXT, only the first three characters of the extension are used to determine the associated program. I tested this by creating a file "test.txta" and adding ".TXTA" to my PATHEXT variable. Typing ".\test" in PowerShell opened the file in my text editor. This only affects PowerShell (cmd.exe handles it correctly) and only in the case where you don't specify the extension (".\test.txta"  works fine, and with tab completion, this is probably more likely). It also ignores the associated command line and only uses the executable.

(I'll pass this on to the PowerShell team, though I have no idea how they'll prioritise it, and of course there's probably no fix for existing versions.)

Because we'd be claiming both .pyz and .pyzw, it's possible to work around this issue if we accept that .pyzw files may run with the .pyz program instead of the .pyzw program. Maybe it goes to something other than py.exe that could choose based on the extension. (Since other command-line arguments get stripped, adding an option to py.exe can't be done, and unless the current behaviour is for it to open .pyw files in pythonw.exe, I wouldn't want it to be different for .pyzw files.)

However, anywhere in Windows that uses ShellExecute rather than FindExecutable will handle long extensions without any issue. AFAIK, this is everywhere except PowerShell, so I don't really see a strong case for breaking the w-suffix convention here. 

Cheers,
Steve