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

[Steven D'Aprano]

On 03/05/13 20:37, Paul Moore wrote:
> On 2 April 2013 01:47, Daniel Holth <dholth at gmail.com> wrote:
>
>> This PEP proposes to fix these problems by re-publicising the feature,
>> defining the .pyz and .pyzw extensions as “Python ZIP Applications”
>> and “Windowed Python ZIP Applications”, and providing some simple
>> tooling to manage the format.
>>
>
> There is a bug in Windows Powershell, which is apparently due to a bug in
> the underlying FindExecutable API, that can fail to recognise extensions
> which are longer than 3 characters properly.

Are you referring to this one?

https://groups.google.com/group/microsoft.public.vb.general.discussion/browse_thread/thread/109aaa1c7d6a31a7/76f9a67c39002178?hl=en


That's pretty old, is it still a problem? Besides, if I'm reading this properly:

http://msdn.microsoft.com/en-us/library/bb776419(VS.85).aspx

the issue is that they should be using AssocQueryString, not FindExecutable.


> Rather than risk obscure bugs, I would suggest restricting the extensions
> to 3 characters. For the “Windowed Python ZIP Applications” case, could we
> use .pzw as the extension instead of .pyzw?

I've had Linux systems which associated OpenOffice docs with Archive Manager rather than OpenOffice. It's likely that at least some Linux systems will likewise decide that .pyz files are archives, not Python files, and open them in Archive Manager. I don't believe that it is Python's responsibility to work around bugs in desktop environments' handling of file associations.

Many official Microsoft file extensions are four or more letters, e.g. docx. I don't see any value in making long-lasting decisions on file extensions based on (transient?) bugs that aren't our responsibility.



-- 
Steven