On Sep 26, 2017, at 11:27, R. David Murray <report@bugs.python.org> wrote:
> 
> Precompiling as a compile-time optimization would be cool.  I think we are currently favoring doing that kind of thing as an AST optimization step?

I was thinking about that too.

> I think Raymond and my point was that the current behavior should remain unchanged by default.  So a re.DEFERRED flag whose default is False would be a possible candidate for the "new API" I suggested :)

Yep, it’s definitely a behavior change, so its the classic “add a new api and most projects won’t get the benefits until they opt-in” problem.  But the problem with that of course is that there are module global re.compiles *everywhere* including probably most commonly in libraries X dependencies deep, which you can’t opt into even if you know it’s safe.  There are probably ways to deal with that, but it all adds complexity.  So adding a deferred compilation API may be valuable, but only in the very long run.

The backward compatibility issue may indeed be the fatal flaw here.  I’m not sure whether the far future payoff is worth adding the new API.  Maybe, but let’s see how far we can get in the meantime.

> However, compile time optimization could default to on like our peephole optimizations do[*], I don't think anyone would be upset about that.
> 
> [*] There are complaints that you can't turn them *off*, but that's a separate issue :)

Yep!  I think I’m going to see if I can make any interesting progress on that, and we’ll just leave this issue open as a placeholder in the meantime.