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

Chris Jerdonek chris.jerdonek at gmail.com
Thu May 3 21:44:39 EDT 2018

FYI, a lot of these ideas were discussed back in September and October of 2017 on this list if you search the subject lines for "startup" e.g. starting here and here: https://mail.python.org/pipermail/python-dev/2017-September/149150.html https://mail.python.org/pipermail/python-dev/2017-October/149670.html

At the end Guido kicked (at least part of) the discussion back to python-ideas.

--Chris

On Thu, May 3, 2018 at 5:55 PM, Chris Angelico <rosuav at gmail.com> wrote:

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.freezemodule() 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

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ chris.jerdonek%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180503/ae46f355/attachment.html>

More information about the Python-Dev mailing list