Thanks Carl, > On Apr 9, 2022, at 08:25, Carl Meyer <[email protected]> wrote: > > Our experience in practice, though, has been that universally lazy > imports is somewhat easier to adopt than Strict Modules, and has had a > much bigger overall impact on reducing startup time for big CLIs (and > a big web server too; as you note it's not as serious an issue for a > web server in production, but restart time still does make a > difference to dev speed / experience.)
Excellent point about the impact of restarts and development time. That’s been an issue for us a bit, but not an overwhelming motivation to rewrite in other languages[1]. > Removing slow stuff happening > at import time helps, but it'll never match the speed of not doing the > import at all! We've seen startup time improvements up to 70% in > real-world CLIs just by making imports lazy. We've also opened an > issue to discuss the possibility of upstreaming this. [2] > > [1] https://github.com/facebookincubator/cinder/#strict-modules > [2] https://bugs.python.org/issue46963 Post-GH-issues-migration link for the issue: https://github.com/python/cpython/issues/91119 I’ve put some questions and comments there, but I’m also really curious about the technical details for your lazy imports. Have you gotten as far as thinking about a PR or PEP? -Barry [1] Not that there aren’t other reasons folks give for rewriting, such as multicore performance, ecosystem alignment (e.g. SREs being more comfortable in Go), etc.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/47BLABCM4G3DQ5WE5MDGY2ISOHHTTUHO/ Code of Conduct: http://python.org/psf/codeofconduct/
