[kokada]

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?

[llimllib]

3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...

[javcasas]

> 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.

[fulafel]

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'?

[estebank]

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.

[tuveson]

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.

[estebank]

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.

[tuveson]

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).

[vic20forever]

Say whaaat? VB (v.3 through v.6, at least) wouldn't compile if you misspelled the name of a function or subroutine.

[aix1]

Funny, yes, but IMO a terrible idea. :)

It would help the writer once, but impose a cost on all future readers for the lifetime of the code.

It's a bit like reading English with bits of German, French and Russian. All of sudden you have to know that Buch, livre and книга all mean the same thing.

Not to mention that there are often subtle differences in meaning between words that on the face of it seem equivalent (in both human and computer languages).

It could be a nice feature for an IDE though, to help someone learn a language.

[QuesnayJr]

Lisp had a package for that, DWIM, in the late 60s: https://en.wikipedia.org/wiki/DWIM.

[orthoxerox]

At the very least Python could quit on `quit` instead of saying that it knows what I want, but won't do it.

[nickserv]

If you have a variable named `quit`, you would have a different behavior in running a file vs running in the CLI.

[sirsinsalot]

Fuzzy function calling. What could go wrong?!

[meowface]

IMO this is bad, but a formatter that autofixes it would be fine

[pansa2]

`npm isntall`

[MarkusQ]

I hope you mean "funny" in the "hilarity ensues" sense.

Because the alternative is a rather sociopathic level of schadenfreude.

[tuveson]

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…

[brainzap]

thats cool, I have the problem alot because I switch languages multiple times per day

[embedding-shape]

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.

[estebank]

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.

[kzrdude]

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?

[js2]

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.

[kzrdude]

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.

[js2]

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.

[toxik]

So the future behavior is deprecated before it ever became the default?

[nyrikki]

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.

It has a good overview of the history.

https://peps.python.org/pep-0749/

[js2]

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! :-)

[karpetrosyan]

Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions

[saghm]

Somehow I have no trouble imagining this being used as a rationale to avoid unnecessary "magic" to the language for years

[tehnub]

Opus 4.7 did this in my code and I had never seen it before

[Hamuko]

It'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]

I 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.

[alcazar]

This 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]

Python 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.

[boxed]

Yes, 3.15+