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/UX6EJHLJNNLMFPWVPF5ANYHQSHDZK7SV/
Code of Conduct: http://python.org/psf/codeofconduct/


--
--Guido van Rossum (python.org/~guido)
Pronouns: he/him (why is my pronoun here?)