[Python-Dev] Existence of pythonNN.zip in sys.path

Eric V. Smith eric at trueblade.com
Wed May 7 20:02:19 CEST 2014


On 05/07/2014 01:13 PM, Terry Reedy wrote:
> On 5/7/2014 7:45 AM, Eric V. Smith wrote:
>> On 5/6/2014 1:14 PM, Terry Reedy wrote:
>>> On 5/5/2014 5:32 PM, Anthony Tuininga wrote:
>>>> Hi,
>>>>
>>>> I am the author of cx_Freeze which creates "frozen" executables from
>>>> Python scripts. To this point I have been using frozen modules
>>>> (compiled
>>>> C) but this has the side effect of bundling parts of Python with a
>>>> cx_Freeze release -- and this has bitten me on a number of occasions
>>>> when newer versions of Python use slightly incompatible modules. :-)
>>>>
>>>> By scanning the code I discovered that Python automatically searches on
>>>> startup
>>>>
>>>> <PYTHONHOME>/lib/pythonNN.zip
>>>>
>>>> where NN is replaced by the major and minor version that is being
>>>> executed. Using this would allow me to ensure that bootstrap modules
>>>> are
>>>> not bundled with cx_Freeze but acquired from the distribution that is
>>>> actually using it -- thereby eliminating the hassle noted above.
>>>>
>>>> I have tested this approach and found it works flawlessly. There is,
>>>> however, no documentation that I can find for the contents of sys.path
>>>> -- the documentation simply says that it is an installation default and
>>>> doesn't specify what that default is.
>>>>
>>>> So my question is: can I safely make use of this "feature"? It has
>>>> remained in place since at least Python 2.6 but I don't want to assume
>>>> anything. Please advise! Thanks.
>>>
>>> I would say yes. AFAIK /lib has always by used for the stdlib on Windows
>>> and /lib/pythonxy on *nix. Both are mentioned in the 4th paragraph of
>>> the site module doc. We do not lightly change directory structure. PEP
>>> 273 then says "The zip archive must be treated exactly as a subdirectory
>>> tree,". I take this to mean that lib/pythonxy.zip should work the same
>>> as lib/pythonxy/ does.
>>>
>>> You can depend on the feature working as long as it works. Your bigger
>>> worry is accidental regression. I suggest testing release candidates
>>> (there is one for 3.4.1 now, I believe) and also an early alpha and beta
>>> for new release. The candidate may have a zip patch affecting central
>>> directory reading. If not, there is an issue on the tracker. You could
>>> monitor patches by filtering the new-issue announcements for 'zip'.
>>
>> The best course of action would be to integrate any such tests into the
>> stdlib test suite, where a regression would immediately be detected.
> 
> We do not and should not put tests of 3rd party products that we do not
> distribute ourselves into the stdlib test suite. Anthony should test
> *his* pythonxy.dll himself. To the extent feasible, we should test the
> promised behavior of python.exe regardless of what any 3rd party
> developer does.
> 
> If pythonxy.zip supplements rather than replacing pythonxy/*.py, this
> should be easy enough: copy .zip into place, run python in a subprocess,
> check the result, delete .zip.

I'm sorry, I misread this. I thought the question was about putting the
stdlib itself in pythonxy.zip. I agree we shouldn't test someone else
using that filename.

Eric.




More information about the Python-Dev mailing list