Comment by kokada
5 hours ago
From this example:
lazy from typing import Iterator
def stream_events(...) -> Iterator[str]:
while True:
yield blocking_get_event(...)
events = stream_events(...)
for event in events:
consume(event)
Do we finally have "lazy imports" in Python? I think I missed this change. Is this also something from Python 3.15 or earlier?
3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...
> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent
Oh, that is such a nice thing.
It's unrelated to the lazy keyword. Instead it's another feature related to error messages.
The example:
1 reply →
Now I'm wishing for a single cross-language library, that I can somehow inject into every compiler/runtime/checker to get this, but with a single source of truth and across a wide range of languages. I hit this damn issue all the time, writing code in one language for another, would truly be a bliss to have that problem solved once and for all.
1 reply →
What benefit does the lazy import have here - if we use the value in a type hint at module scope anyway? Would that require Deferred evaluation of annotations -- which I don't think are enabled by default?
Type annotations are lazily evaluated by moving them behind a special annotations scope as of 3.14:
https://peps.python.org/pep-0649/
https://docs.python.org/3/reference/compound_stmts.html#anno...
With 3.15, using lazy typing imports is more or less an alternative to putting such imports behind an "if TYPE_CHECKING" guard.
Ah, thanks for the update. My only check before asking was to check if the future feature for annotations had been enabled by default yet. It has then effectively been abandoned instead, I guess.
4 replies →
[dead]
Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions
Somehow I have no trouble imagining this being used as a rationale to avoid unnecessary "magic" to the language for years
[dead]
Yes, 3.15+
[dead]
Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports (1% of which are probably Shai Hulud now).
And now even type imports are apparently so slow that you have to disable them if unused during the normal untyped execution.
If Instagram or others wants a professional language, they should switch to Go or PHP instead of shoehorning strange features into a language that wasn't built for their use cases.
> Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports
Just because you don’t like a feature doesn’t mean it’s because of AI and bad code.
Too much syntactic sugar causes cancer of the semicolon.
I think this is just a natural consequence of an easy-to-use package system. The exact same story as with node. If you don't want lots of imports, don't make it so damn easy to pile them into projects. I'm frankly surprised we still see so few supply chain attacks, even though they picked up their cadence dramatically.
5 replies →
True, but this is yet another code path that isn't exercised until specific conditions happen. That means even more latent application behaviour can go undetected by unit testing and security profiling until the moon is in the right phase, which is a boon for submarine attacks.
Empirically, I have used the current accepted way to do lazy imports (import statement inside a function) before AI coding was even a mainstream thing, for personal code that sometimes needs a heavy import and sometimes doesn’t.
The lazy statement would be an improvement as it allows one to see all the imports at the top where you expect them to be.
As a now deleted comment pointed out, lazy imports had been requested forever. They were rejected forever and were accepted just when BigCorps wanted them.
Python-dev now is paid to shore up the failed Instagram stack.
7 replies →
On most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.