On Sep 15, 2014, at 7:34 AM, Lucas Alvares Gomes <[email protected]> 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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
