5/21/2026 at 11:54:58 AM
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)
by kokada
5/21/2026 at 12:28:01 PM
3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...by llimllib
5/21/2026 at 1:40:41 PM
> 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 equivalentOh, that is such a nice thing.
by javcasas
5/21/2026 at 4:26:50 PM
It'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'?by fulafel
5/21/2026 at 4:49:32 PM
In 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.
by estebank
5/21/2026 at 5:09:57 PM
I’ve often thought it would be funny if instead of an error message for stuff like this, a language could be designed to be “typo-insensitive”. If a method or function call is similar enough to an existing one or a common one from other languages, to just have it silently use that.by tuveson
5/21/2026 at 5:23:13 PM
VisualBasic did that. I think it is a mistake. But that doesn't mean that the compiler can't detect that and tell you how to fix it instead.by estebank
5/21/2026 at 6:07:36 PM
Sure VB ignores case, but what I want is for it to compare each method against a dictionary of similar terms. And maybe calculate the Levenshtein distance between all terms if it’s not found, and just assume it’s the closest one. You could also assume that full-width characters or similar-looking glyphs are equivalent (BASIC was pre-Unicode, so I can forgive them for not including that).by tuveson
5/21/2026 at 5:58:39 PM
Lisp had a package for that, DWIM, in the late 60s: https://en.wikipedia.org/wiki/DWIM.by QuesnayJr
5/21/2026 at 5:18:25 PM
I hope you mean "funny" in the "hilarity ensues" sense.Because the alternative is a rather sociopathic level of schadenfreude.
by MarkusQ
5/21/2026 at 5:55:37 PM
Yes, I say “funny” because it would be impractical and weird, definitely not a good idea. It’s already a bad enough that so many popular languages don’t (and can’t) check if a field or method is misspelled at compile time…by tuveson
5/21/2026 at 6:50:05 PM
We already have it. In fact, Python added it with this change! Not intentionally, but in a world of AI, any error message containing a suggestion of what to do to fix it is a directive to the AI to actually do that thing.Example: to build our system, you run `mach build`. For faster rebuilds, you can do `mach build <subdir>`, but it's unreliable. AI agents love to use it, often get errors that would be fixed by a full-tree build, and will chase their tails endlessly trying to fix things that aren't broken. So someone turned off that capability by default and added a flag `--allow-subdirectory-build` for if you want to use it anyway. So that people would know about it, they added a helpful warning message pointing you to the option[1].
The inevitable (in retrospect) happened: now the AI would try to do a subdirectory build, it would fail, the AI would see the warning message, so it would rerun with the magic flag set.
So now the warning message is suppressed when running under an AI[2][3]. The comment says it all:
# Don't tell agents how to override, because they do override
[1] https://searchfox.org/firefox-main/rev/fc94d7bda17ecb8ac2fa9...
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=2034163
[3] https://searchfox.org/firefox-main/rev/cebc55aab4d2661d1f6c2...
by sfink
5/21/2026 at 4:03:45 PM
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.by embedding-shape
5/21/2026 at 4:57:03 PM
If 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.by estebank
5/21/2026 at 2:17:06 PM
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?by kzrdude
5/21/2026 at 3:00:52 PM
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.
by js2
5/21/2026 at 3:15:22 PM
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.by kzrdude
5/21/2026 at 3:42:22 PM
Yup, "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.
by js2
5/21/2026 at 4:15:09 PM
So the future behavior is deprecated before it ever became the default?by toxik
5/21/2026 at 4:44:15 PM
It was an abandoned path even before 3.10, it just took longer to implement 649 and 749 than they expected.But this is a "...will continue to exist with its current behavior at least..." is an important bit there.
From pep-0749:
Sometime after the last release that did not support PEP 649 semantics (expected to be 3.13) reaches its end-of-life, from __future__ import annotations is deprecated. Compiling any code that uses the future import will emit a DeprecationWarning. This will happen no sooner than the first release after Python 3.13 reaches its end-of-life, but the community may decide to wait longer.
by nyrikki
5/21/2026 at 4:42:46 PM
Correct. Before the "from __future__ import annotations" behavior that converts annotations to strings became the default, they figured out a better mechanism for circular type annotations (making them lazy) that is implicitly backwards compatible and that didn't need to be guarded behind a future statement.Ironically, the new default behavior (making type annotation evaluation lazy) is not backwards compatible with the "from __future__ import annotations" behavior of converting annotations to strings, so they can't just rip out "from __future__ import annotations" and instead it needs to be deprecated and removed over multiple releases.
Oh, what tangled webs we weave! :-)
by js2
5/21/2026 at 2:58:58 PM
[dead]by athorax
5/21/2026 at 12:51:12 PM
Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versionsby karpetrosyan
5/21/2026 at 1:15:52 PM
Somehow I have no trouble imagining this being used as a rationale to avoid unnecessary "magic" to the language for yearsby saghm
5/21/2026 at 2:12:00 PM
[dead]by wrmsr
5/21/2026 at 11:59:43 AM
Yes, 3.15+by boxed
5/21/2026 at 4:03:51 PM
[dead]by alcazar
5/21/2026 at 12:17:34 PM
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.
by rad120
5/21/2026 at 12:20:24 PM
> Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 importsJust because you don’t like a feature doesn’t mean it’s because of AI and bad code.
by stingraycharles
5/21/2026 at 12:25:21 PM
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.by sigmoid10
5/21/2026 at 1:10:37 PM
This 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.by saghm
5/21/2026 at 1:15:04 PM
> it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed onesCounter-example is Go and init() function.
by kokada
5/21/2026 at 6:47:18 PM
Static initializers in C++ - sometime ago I saw savings of some 400 ms (?) startup cost of initializing static strings from constants by moving it to some compile time thing.by lanstin
5/21/2026 at 7:17:39 PM
Right; the issue is that this isn't happening at compile time in Python, because it's not getting compiled ahead-of-time. The equivalent would be if header files had imperative code that got executed at runtime in places where they're included.(To preempt potential pedantry: yes, I know that you can compile Python to bytecode ahead of time, but that's not really relevant to what's being discussed here because it doesn't mean "the stuff happening in modules I import isn't happening at runtime anymore")
by saghm
5/21/2026 at 1:52:48 PM
Interesting, 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)by saghm
5/21/2026 at 3:40:07 PM
Also C++/Java static initialization, C# static constructors, or Rust global variable initialization, ...Most languages have this feature Afaik
by assbuttbuttass
5/21/2026 at 6:25:51 PM
Rust 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.by ameliaquining
5/21/2026 at 7:22:47 PM
[dead]by saghm
5/21/2026 at 6:23:53 PM
IIUC 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.by ameliaquining
5/21/2026 at 1:11:46 PM
What would your alternative look like?by stevesimmons
5/21/2026 at 2:24:04 PM
Too much syntactic sugar causes cancer of the semicolon.by xtajv
5/21/2026 at 2:28:45 PM
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.by tremon
5/21/2026 at 12:36:59 PM
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.
by novov
5/21/2026 at 12:44:20 PM
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.
by afH12
5/21/2026 at 5:08:48 PM
both lazy imports and free threading have been proposed ages ago, they both went through several iterations before a good design was settled upon and made it into the language.in the case of lazy imports the big corps were the ones doing the experimentation and iteration. the feature didn't make it into the language "just when big corps wanted them"; the instagram stack you allude to already had its own fork of cpython with lazy imports added years ago, and that is not the design that ended up getting adopted by upstream cpython, though some of the people working on it also collaborated on the PEP that finally did make it in.
by zem
5/21/2026 at 3:40:36 PM
It was accepted just as multiple large corporations with competent teams of internal tool departments ended up forking the interpreter to support lazy imports and demonstrated empirically that the idea has merit.by Daishiman
5/21/2026 at 1:01:04 PM
I too am outraged that a product would prioritize its biggest users.by brookst
5/21/2026 at 1:14:14 PM
Is 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.by saghm
5/21/2026 at 1:32:56 PM
If 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.
by brookst
5/21/2026 at 4:00:31 PM
Not to mention when the single, tangible, vocal stakeholder can also be asked to be responsible for documentation (PEPs, etc) and PRs. Especially in open source there is a huge difference between "a lot of people asked about this" and "one person asked about this, but was passionate enough about it and open enough to following the process and the feedback loops to champion it all the way across the finish line".by WorldMaker
5/21/2026 at 4:37:57 PM
I don't have any issue with what you're saying if that's what happened. There's quite a gap between that sort of reasoned explanation and treating concerns about large stakeholders versus large numbers of small one with derision.by saghm
5/21/2026 at 5:33:15 PM
For what it is worth, I was trying not to make a value judgment on it, especially not with relation to this specific instance, I was hopefully just recognizing it as a motivating factor in general open source politics. Sometimes that is quite regretful because it is anti-democratic and does look like favoritism or worse cronyism when it plays out in that way of "we listened to the person/company that built and tested a prototype and did all the work to standardize and then PR it over the many developers that wanted an idea but didn't have the time/money/bandwidth to implement it themselves".by WorldMaker
5/21/2026 at 7:12:49 PM
That's fair. I think I mostly reacted because of the sarcastic faux-outrage that the original comment I responded to expressed. These are hard problems, and I think the presumption should be someone being frustrated at the slow state of changes they want probably has legitimate reasons to feel that way, just as the presumption should be that open-source projects that have run successfully for a long time probably are making good-faith effort to steward what they're maintain. Acknowledging the tension between priorities not lining up exactly for everyone and not having knee-jerk reactions when someone is unhappy seems preferable to mocking those who you disagree with.by saghm
5/21/2026 at 1:50:27 PM
I 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.by saghm
5/21/2026 at 12:42:48 PM
On most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.by formerly_proven