On 5/26/14 10:40 PM, Nick Coghlan wrote:

On 27 May 2014 10:28, "Ned Batchelder" <ned@nedbatchelder.com> wrote:
>
> On 5/23/14 1:22 PM, Guido van Rossum wrote:
>>
>> On Fri, May 23, 2014 at 10:17 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
>>>
>>> On Fri, May 23, 2014 at 10:49 AM, Guido van Rossum <guido@python.org> wrote:

>>>
>>> Would it be a problem if .pyc files weren't generated or used (a la -B
>>> or PYTHONDONTWRITEBYTECODE) when you ran coverage?
>>
>>
>> In first approximation that would probably be okay, although it would make coverage even slower. I was envisioning something where it would still use, but not write, pyc files for the stdlib or site-packages, because the code in whose coverage I am interested is puny compared to the stdlib code it imports.
>
>
> I was concerned about losing any time in test suites that are already considered too slow. But I tried to do some controlled measurements of these scenarios, and found the worst case (no .pyc available, and none written) was only 2.8% slower than full .pyc files available. When I tried to measure stdlib .pyc's available, and no .pyc's for my code, the results were actually very slightly faster than the typical case. I think this points to the difficult in controlling all the variables!
>
> In any case, it seems that the penalty for avoiding the .pyc files is not burdensome.

Along these lines, how about making the environment variable something like "PYTHONANALYSINGSOURCE" with the effects:

- bytecode files are neither read nor written
- all bytecode and AST optimisations are disabled

A use case oriented flag like that lets us tweak the definition as needed in the future, unlike an option that is specific to turning off the CPython peephole optimiser (e.g. we don't have an AST optimiser yet, but turning it off would still be covered by an "analysing source" flag).

My inclination would still be to provide separate controls like "DISABLE_OPTIMIZATIONS" and "DISABLE_BYTECODE", these are power tools in any case. What is the process from this point forward? A patch? A PEP?

--Ned.

Cheers,
Nick.

>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/