<div dir="ltr">Let's kick this part of the discussion back to python-ideas.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 17, 2017 at 1:36 PM, Michel Desmoulin <span dir="ltr"><<a href="mailto:desmoulinmichel@gmail.com" target="_blank">desmoulinmichel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe it's time to bring back the debate on the "lazy" keyword then ?<br>
Rendering any statement arbitrarily lazy could help with perfs. It would<br>
also make hacks like ugettext_lazy in Django useless. And would render<br>
moot the extensions of f-strings for lazily rendered ones. And bring<br>
lazy imports in the mix.<br>
<div><div class="h5"><br>
Le 17/10/2017 à 19:39, Neil Schemenauer a écrit :<br>
> Christian Heimes <<a href="mailto:christian@python.org">christian@python.org</a>> wrote:<br>
>> That approach could work, but I think that it is the wrong<br>
>> approach. I'd rather keep Python optimized for long-running<br>
>> processes and introduce a new mode / option to optimize for<br>
>> short-running scripts.<br>
><br>
> Another idea is to run a fake transasaction through the process<br>
> before forking. That will "warm up" things so that most of the lazy<br>
> init is already done.<br>
><br>
> After returning from the core sprint, I have gotten over my initial<br>
> enthusiam for my "lazy module defs" idea. It is just too big of a<br>
> change for Python to accept that this point. I still hope there<br>
> would be a way to make LOAD_NAME/LOAD_GLOBAL trigger something like<br>
> __getattr__(). That would allow libraries that want to aggressively<br>
> do lazy-init to do so in the clean way.<br>
><br>
> The main reason that Python startup is slow is that we do far too<br>
> much work on module import (e.g. initializing data structures that<br>
> never get used). Reducing that work will almost necessarily impact<br>
> pre-fork model programs (e.g. they expect the init to be done before<br>
> the fork).<br>
><br>
> As someone who uses that model heavily, I would still be okay with<br>
> the "lazification" as I think there are many more programs that<br>
> would be helped vs the ones hurt. Initializing everything that your<br>
> program might possibibly need right at startup time doesn't seem<br>
> like a goal to strive for. I can understand if you have a different<br>
> opinion though.<br>
><br>
> A third approach would be to do more init work at compile time.<br>
> E.g. for re.compile, if the compiled result could be stored in the<br>
> .pyc, that would eliminate a lot of time for short scripts and for<br>
> long-running programs. Some Lisp systems have "compiler macros".<br>
> They are basically a hook to allow programs to do some work before<br>
> the code is sent to the compiler. If something like that existed in<br>
> Python, it could be used by re.compile to generate a compiled<br>
> representation of the regex to store in the .pyc file. That kind of<br>
> behavior is pretty different than the "there is only runtime" model<br>
> that Python generally tries to follow.<br>
><br>
> Spit-ball idea, thought up just now:<br>
><br>
> PAT = __compiled__(re.compile(...))<br>
><br>
> The expression in __compiled__(..) would be evaluated by the<br>
> compiler and the resulting value would become the value to store in<br>
> th .pyc. If you are running the code as the script, __compiled__<br>
> just returns its argument unchanged.<br>
><br>
> Cheers,<br>
><br>
> Neil<br>
><br>
> ______________________________<wbr>_________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
</div></div>> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/desmoulinmichel%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>desmoulinmichel%40gmail.com</a><br>
<div class="HOEnZb"><div class="h5">><br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>