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 <guido@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 <mborch@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-leave@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/UX6EJHLJ... 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-leave@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/BTWPAJRV... Code of Conduct: http://python.org/psf/codeofconduct/