I have posted this Idea on Python Discussions, and Thomnas Wouters replied to it and to others:
https://discuss.python.org/t/pep-810-explicit-lazy-imports/1...
The specific part of the PEP:
https://github.com/python/peps/pull/4628/files#diff-ca011267...
I think your assessment of what's "the right/wrong" syntax is fair. But the transition you describe takes a long time, even now that the community has figured out a "deprecation cycle" process that seems satisfactory (i.e. won't lead to another Python 3.0 situation).
> All which authors of old code would have to do is run a provided fix script in the root directory of their code.
As I recall, `lib2to3` didn't do a lot to ease tensions. And `six` is still absurdly popular, mainly thanks to `python-dateutil` still attempting to support 2.7.
Honestly, I don't care for 2 to 3 or six (which, btw, has just 1k stars on GitHub, compare to e.g. 90k stars for FastAPI). Someone who bases their code on 2.7 in 2025 must expect to run into trouble.
If people do not run such upgrade scripts, it must be documented better.
Python is free. In order to also stay elegant, they should say to their users: "We expect from you to run an upgrade script on your code once per Python upgrade"
In short, grandiose change, wrong syntax.
They make that, what should be the default, a special case. Soon, every new code will use "lazy". The long term effect of such changes is a verbose language syntax.
They should have had a period where one, if they want lazy imports, has to do "from __future__ import lazy_import". After that period, lazy imports become the default. For old-style immediate imports, introduce a syntax: "import now foo" and "from foo import now bar".
All which authors of old code would have to do is run a provided fix script in the root directory of their code.