Start up overhead due to imports is a real problem for some class of applications, e.g. CLIs, and I’ve seen a lot of hacks implemented to get Python CLIs to be more responsive. E.g. getting from invocation to —help output is a major UX problem.
It’s often more complicated than just imports alone though. Expensive module
scope initializations and decorators contribute to this problem. Python start
up time is one of the main drivers for rewriting CLIs in Go and other languages
where I work. Note that this is much less of a problem for things like web
services or other long running applications because that start up time is
either amortized over the lifetime of the application, or aren’t directly
visible to the end user.
Lazy imports *might* help with this and seems aligned with the common trick of
moving imports into functions rather than at module scope. Faster CPython
might help too. But these all feel like they aren’t tackling the start up
problem head on[1]. Lots of ideas have been discussed over the years (I
remember some in-depth ones at the Microsoft core sprint a few years ago), and
I’m sure there are all kinds of other tricks that people use.
However, if start up time isn’t a direct benefit of on-demand imports (a.k.a.
declarative imports), I’m not sure how actually useful or used they will be. I
dunno, top-of-module imports never really bothered me that much.
-Barry
[1] I could be wrong about Faster CPython; ISTR there are some tickets on that
project’s tracker that talk about start up times.
> On Apr 8, 2022, at 09:40, Guido van Rossum <gu...@python.org> wrote:
>
> The interesting idea here seems to make "lazy imports" easier to implement by
> making them explicit in the code. So far, most lazy import frameworks for
> Python have done hacks with `__getattribute__` overrides. IIRC the Cinder
> version even modifies the bytecode and/or the interpreter. Disregarding the
> specific notation proposed, *if* people would be willing to mark the points
> where they expect lazy imports explicitly, that would make implementation
> much simpler.
>
> The argument that "imports on top" makes code more readable seems pretty weak
> to me. The current hacks to speed up startup already violate this rule
> (imports inside functions), and in most cases I start reading or writing code
> in the middle of a file (having gotten there via a search in my editor) and
> the meaning of an import is either obvious (e.g. re.match(...)) or requires
> another annoying search to find the definition of a certain unknown variable.
> Tools can easily show all imports a module does.
>
> The key questions to me are
> - What should the notation be?
> - Will users be willing to use it?
>
> --Guido
>
>
>
> On Fri, Apr 8, 2022 at 1:26 AM Malthe <mbo...@gmail.com> wrote:
> This is an idea which has been brought up before, sometimes introduced
> as "heresy". But an interesting twist has surfaced now which is
> typing.
>
> But firstly, let me present the idea. It is very simple, that Python
> should have declarative imports, usable anywhere using a simple
> syntax, @<dotted-name>.
>
> For example, `some_regex = @re.compile(...)`.
>
> What happens then is that before anything else in that module, that
> symbol is imported:
>
> from re import compile as _mangled_re_compile
>
> It must be the very first thing (hoisting) because when else would it
> happen? It's been suggested before to have a shorthand syntax which
> does a dynamic import at the time of using it but this brings me to
> the twist:
>
> We want typing to pick up these imports. And this twist has a second
> leg which is that we often need to import symbols simply in order to
> type some argument type or return type. This leads to a great many
> more imports to type.
>
> (Nevermind that if you want to take typing further, abstract
> interfaces really make more sense rather than specific
> implementations, but the point is the same.)
>
> A situation where this would come in really handy is in scripting such
> as how we use Python in Apache Airflow to let users write out simple
> workflows. A workflow definition which could be a 5-liner quickly
> becomes a 20-liner – consider for example:
>
> default_args = {
> "start_date": @datetime.datetime(...)
> }
>
> It's a lot more ergonomic from a user perspective (well perhaps for
> some users and for some programs).
>
> Thoughts?
>
> Cheers
> _______________________________________________
> 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/UX6EJHLJNNLMFPWVPF5ANYHQSHDZK7SV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> _______________________________________________
> 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/BTWPAJRVQ24QX2Z7TIQPDYRXKJOGRPMU/
> Code of Conduct: http://python.org/psf/codeofconduct/
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/6MYCFBEFR4K6XR7VPPVJMT5KLO35GWBD/ Code of Conduct: http://python.org/psf/codeofconduct/
