Thanks Carl, > On Apr 9, 2022, at 08:25, Carl Meyer <c...@oddbird.net> 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 -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/47BLABCM4G3DQ5WE5MDGY2ISOHHTTUHO/ Code of Conduct: http://python.org/psf/codeofconduct/
