On Sun, Feb 7, 2010 at 12:23 PM, Brett Cannon <br...@python.org> wrote: > 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).
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) _______________________________________________ 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
