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 <ros...@gmail.com> wrote: > On Fri, May 4, 2018 at 10:43 AM, Gregory P. Smith <g...@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 compile_time_decorators # we'd be unlikely to > ever > > change the default and break things, __future__ seems wrong > > > > @this_happens_at_compile_time(3) > > def ... > > > > @:this_waits_until_runtime(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 > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > chris.jerdonek%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
