6 ms·
From this example: lazy from typing import Iterator def stream_events(...) -> Iterator[str]: while True: yield blocking_get_event(
by kokada 5mo 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?
- boxed 5mo agoYes, 3.15+
- rad120 5mo ago[flagged]
- stingraycharles 5mo ago> 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.
- sigmoid10 5mo agoI 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.
- saghm 5mo agoThis seems a lot more due to an import running arbitrary code because stuff can happen in the top-level of a module rather than only happening in functions. From what I can tell, it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones, which tend to have a main function that everything else happens inside transitively. I guess this makes it easy if what you're writing is something that runs with no dependencies, but it's a pretty terrible experience as soon as you try to introduce the concept of a library.
- kokada 5mo ago> it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones Counter-example is Go and init() function.
- saghm 5mo agoInteresting, I had no idea that existed! I still think there's a a difference between "here's a hook you can use to run stuff earlier" and "importing any module is fundamentally the same as running it as a script unless the module happens to use a special conditional to wrap stuff inside of" though (and I say this as someone who doesn't go out of his way to defend Go design decisions)
- assbuttbuttass 5mo agoAlso C++/Java static initialization, C# static constructors, or Rust global variable initialization, ... Most languages have this feature Afaik
- ameliaquining 5mo agoRust doesn't have this behavior (sometimes called "life before main"). Code to initialize a static variable runs either at compile time, or lazily on first access, depending on which mechanism you use.
- saghm 5mo agoYeah, I don't think that "precompute something at compile-time" is really comparable to "every import literally executes code as a script". Rust imports are actually about as far from this as I can imagine, because modules can circularly reference each other, which unless I'm misunderstanding would be an infinite loop in Python without manually breaking the chain with some form of conditional. I'm actually kind of surprised to see comments like that one, because compile-time logic feels like the opposite end of the spectrum from what Python imports do, with "regular" code being compiled without any precomputation sitting somewhere in the middle. It seems like I didn't articulate my thoughts clearly enough though, since several people seemed to read what I was saying as being comparable.
- stevesimmons 5mo agoWhat would your alternative look like?
- ameliaquining 5mo agoIIUC the organizations that most strongly pushed for this feature are big companies with large codebases. These tend not to be the kinds of orgs that just casually pull in dependencies from PyPI on a whim; I think it more likely that the quantity of first-party code was so large that importing all of it on startup was causing problems.
- sirsinsalot 5mo agoI worked in a codebase like this. The load time was insane. We would also constantly need to put imports in function heads to effectively lazy import due to the massive risk of circular imports. We also had dynamic imports so tracking the cycles was very difficult at times.
- xtajv 5mo agoToo much syntactic sugar causes cancer of the semicolon.
- tremon 5mo agoTrue, 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.
- deleted 5mo ago[deleted]
- ziml77 5mo agoBut also great for speed. Larger libraries can take a measurable amount of time to import (even if they have no transitive dependencies). If only some of your code paths actually need the large library then it makes sense to import it lazily. Without lazy you have to do it conditionally which can lead to the imports happening in strange places rather than all being listed out at the top of the file.
- novov 5mo agoEmpirically, 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.
- afH12 5mo agoAs 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.
- brookst 5mo agoI too am outraged that a product would prioritize its biggest users.
- saghm 5mo agoIs the biggest user larger than the combined set of individual users who had asked for (or would benefit from) the same thing? I honestly don't know, but I don't think that things are always as simple as you're implying in a world where we have the collective action problem.
- brookst 5mo agoIf you’re asking some some kind of abstract moral value sense, I have idea. If you’re asking whether project leads give more weight to a single, tangible, vocal stakeholder than they do to unknown numbers of anonymous and lightly-engaged stakeholders? Yes.
- saghm 5mo agoI mean, yes, demonstrably, the phenomenon you're describing happens. Your previous comment seems pretty sarcastically dismissing the idea that someone could disagree with this being a good thing though, and I was making a counterargument against the underlying opinion that seemed apparent.
- formerly_proven 5mo agoOn most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.
- stingraycharles 5mo agoEh, resolving object symbols is something done at runtime. #include absolutely is eager. I wouldn’t compare this in any way to Python’s lazy imports.
- formerly_proven 5mo agoLazy in the sense that by default calls to external symbols will jump through the PLT which will jump into ld and resolve the symbol during the first call to the symbol (ld then patches the PLT to point to the actual function for later calls). Not lazy in the sense that shared objects are resolved at runtime, which is existential to dynamic linkage.
- deleted 5mo ago[deleted]
- llimllib 5mo ago3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-lazy-imports https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...
- javcasas 5mo ago> 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.
- embedding-shape 5mo agoNow 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.
- estebank 5mo agoIf you had a "canonical datastructure database", you could have very short annotations on every standard library for any language that indexes a function to their canonical name. After that you only need to update the database.
- fulafel 5mo agoIt's unrelated to the lazy keyword. Instead it's another feature related to error messages. The example: >> 'hello'.toUpperCase() Traceback (most recent call last): ... AttributeError: 'str' object has no attribute 'toUpperCase'. Did you mean '.upper'?
- estebank 5mo agoIn the Rust toolchain we've done the same. It just so happens that rustdoc already has introduced annotations for "aliases" so that when someone searches for push and it doesn't exist, append would show up. Having those annotations already meant that bootstrapping the feature to check the aliases during name resolution errors in rustc was almost trivial. I love it when improving one thing improves another indirectly too. I really appreciate them going out of their way to do this, being quite aware of the hidden complexity in doing it.
- karpetrosyan 5mo agoNote that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions
- kzrdude 5mo agoWhat 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?
- athorax 5mo ago[dead]
- js2 5mo agoType annotations are lazily evaluated by moving them behind a special annotations scope as of 3.14: https://peps.python.org/pep-0649/ https://peps.python.org/pep-0649/ https://docs.python.org/3/reference/compound_stmts.html#annotations 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.
- kzrdude 5mo agoAh, 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.
- js2 5mo agoYup, "from __future__ import annotations" will eventually be removed: > from __future__ import annotations (PEP 563) will continue to exist with its current behavior at least until Python 3.13 reaches its end-of-life. Subsequently, it will be deprecated and eventually removed.
- toxik 5mo agoSo the future behavior is deprecated before it ever became the default?
- 5mo ago
- alcazar 5mo agoThis one is really nice. Imports in the middle of a file are very ugly but sometimes necessary. This fixes it in a nicer way. However, it kind of goes against the principle that “explicit is better than implicit.”
- ActorNightly 5mo agoPython has had lazy imports from like day one, where you could have an import statement in a function, and the library won't be imported until that function is hit.
- Hamuko 5mo agoIt's one of the headline features of Python 3.15 (hence why it's not in this article). It's even mentioned as the first thing on the What's New doc, so I'm definitely counting it as a "headline feature". Personally, can't wait. It was just this week that I observed a Python process running out of memory because a module import that's not being used during the process was added to the application, and the memory usage went over a critical threshold because of that.
- 0cf8612b2e1e 4mo agoI am left wondering when to use it. Every import, all the time? It is an optimization that benefits some pathological scenarios, but not sure I want to introduce bikeshedding in what is/not lazy.