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). -Brett > > -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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
