[Python-Dev] Python startup time (original) (raw)

Chris Angelico rosuav at gmail.com
Thu May 3 20:55:42 EDT 2018

On Fri, May 4, 2018 at 10:43 AM, Gregory P. Smith <greg at krypto.org> wrote:

I'd also like to see this concept somehow extended to decorators so that the results of the decoration can be captured in the compiled pyc rather than requiring execution at import time. I realize that limits what decorators can do, but the evil things they could do that this would eliminate are things they just shouldn't be doing in most situations. meaning: there would probably be two types of decorators... colons seem to be all the rage these days so we could add an @: operator for that. :P ... Along with a from future import to change the behavior or all decorators in a file from runtime to compile time by default.

from future import compiletimedecorators # we'd be unlikely to ever change the default and break things, future seems wrong @thishappensatcompiletime(3) def ... @:thiswaitsuntilruntime(5) def ... Just a not-so-wild idea, no idea if this should become a PEP for 3.8. (the : syntax is a joke - i'd prefer @@ so it looks like eyeballs)

At this point, we're squarely in python-ideas territory, but there are some possibilities. Imagine popping this line of code at the bottom of your file:

import importlib; importlib.freeze_module()

as a declaration that the dictionary for this module is now locked in and can be dumped out in whatever form is most efficient. Effectively, you're stating that you do not need any sort of dynamism (that call could be easily disabled for testing), and that, if the optimization breaks anything, you accept responsibility for it.

How this would be implemented, I'm not sure, but that's no different from the @: idea.

ChrisA

More information about the Python-Dev mailing list