Open Stack

On Sep 15, 2014, at 7:34 AM, Lucas Alvares Gomes <lucasagomes at gmail.com> wrote:

> 
> So this ordering thing, I don't think that it's caused by the
> PYTHONDONTWRITEBYTECODE, I googled that but couldn't find anything
> relating this option to the way python hash things (please point me to
> a document/code if I'm wrong). Are you sure you're not confusing it
> with the PYTHONHASHSEED option?


not at all, as I have many years of experience with this phenomenon,  but the fact that PYTHONHASHSEED can be used means this particular point is probably moot.

> 
> 
> About the performance, this also doesn't seem to be true. I don't
> think .pyc affects the performance we run things at all, pyc are not
> meant to be an optimization in python. It DOES affect the startup of
> the application tho, because it will have to regenerate the bytecode
> all the time, see [4]:

it is true in the case that an application consumes Python modules in a non-standard way, such that the .py/.pyc files may be read more frequently than just once, depending on how the library is used.   I happen to be the author of two such libraries, one is Mako templates and the other is Alembic, which is used by many openstack projects.

If a test suite for example runs through all of its Alembic migration scripts on every setup/teardown of a test, the presence of .pyc files generated for migration scripts will have a definite effect on the speed of the tests.  Alembic does not place the modules into sys.modules and loads them as they are processed for a migration operation.

Within Alembic, there’s all kinds of features involving .pyc files, such as sourceless setups, non-pyc setups, so to that extent, Alembic’s has behaviors that are explicitly linked directly to whether or not .pyc files are present.