On Thu, May 3, 2018 at 5:22 PM, Lukasz Langa <lukasz@langa.pl> wrote:

> On May 2, 2018, at 8:57 PM, INADA Naoki <songofacandy@gmail.com> wrote:
> Recently, I reported how stdlib slows down `import requests`.
> https://github.com/requests/requests/issues/4315#issuecomment-385584974
> For Python 3.8, my ideas for faster startup time are:
> * Add lazy compiling API or flag in `re` module.  The pattern is compiled
> when first used.

How about go the other way and allow compiling at Python *compile*-time? That would actually make things faster instead of just moving the time spent around.

I do see value in being less eager in Python but I think the real wins are hiding behind ahead-of-time compilation.

Agreed in concept.  We've got a lot of unused letters that could be new string prefixes... (ugh)

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

def ...

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)

If this were done to decorators, you can imagine extending that concept to something similar to allow compile time re.compile calls as some form of assignment decorator:

GREGS_RE = @re.compile(r'A regex compiled at compile time\. number = \d+')


- Ł