[Python-Dev] PEP 3147: PYC Repository Directories

[Guido van Rossum]

On Sun, Feb 7, 2010 at 12:23 PM, Brett Cannon <brett at python.org> wrote:
> On Sun, Feb 7, 2010 at 10:44, Barry Warsaw <barry at python.org> wrote:
>> On Feb 06, 2010, at 04:39 PM, Guido van Rossum wrote:
>>
>>>The conflict is purely that PEP 3147 proposes the new behavior to be
>>>optional, and adds a flag (-R) and an environment variable
>>>($PYTHONPYR) to change it. I presume Barry is proposing this out of
>>>fear that the new behavior might upset somebody; personally I think it
>>>would be better if the behavior weren't optional. At least not in new
>>>Python releases
>>
>> Good to know!  Yes, that's one reason why I made it option, the other being
>> that I suspect most people don't care about the original use case (making sure
>> pyc files from different Python versions don't conflict).  However, with a
>> folder-per-folder approach, the side benefit of reducing directory clutter by
>> hiding all the pyc files becomes more compelling.
>>
>>> -- in backports such as a distribution that wants this
>>>feature might make, it may make sense to be more conservative, or at
>>>least to have a way to turn it off.
>>
>> For backports I think the most conservative approach is to require a flag to
>> enable this behavior.  If we make this the default for new versions of Python
>> (something I'd support) then tools written for Python >= 3.2 will know this is
>> just how it's done.  I worry about existing deployed tools for Python < 2.7
>> and 3.1.
>>
>> How about this: enable it by default in 3.2 and 2.7.  No option to disable it.
>> Allow distro back ports to define a flag or environment variable to enable it.
>> The PEP can even be silent about how that's actually done, and a Debian
>> implementation for Python 2.6 or 3.1 could even use the (now documented :) -X
>> flag.
>
> Would you keep the old behavior around as well, or simply drop it? I
> personally vote for the latter for simplicity and performance reasons
> (by not having to look in so many places for bytecode), but I can see
> tool people who magically calculate the location of the bytecode not
> loving the idea (another reason why giving loaders a method to return
> all relevant paths is a good idea; no more guessing).

For 3.2 I think it's fine to simply drop the old behavior (as long as
a good loader API is added at the same time).

But for 2.7 I think we ought to be a lot more conservative and not
force tools to upgrade, so I think we should keep the old behavior in
2.7 as the default (though distros can change this if they want to,
and backport if they need to).

-- 
--Guido van Rossum (python.org/~guido)