On Sun, Feb 7, 2010 at 10:44, Barry Warsaw <ba...@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).


> -Barry
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
Python-Dev mailing list

Reply via email to