iterator-based API not type-checker friendly

[zsol]

I was intrigued by the iterator + context manager based retry API offered by stamina (great library btw: love the docs, the overall APIs, the types-first approach 👍🏻), but after sprinkling it on some code I was playing with, I noticed this pattern:

foo = await fetch_foo()
print(foo)

# naturally (for me anyway) turns into

async for attempt in stamina.retry_context(Exception, 2):
    with attempt:
        foo = await fetch_foo()
print(foo)

But then type checkers rightfully complain on the last print(foo) call that foo might be unbound. After all, nothing in the types guarantee that the async generator yields anything.

So I have a few choices:

1. declare foo with some default value
2. move the print statement (any any further code) into the context manager scope
3. make a wrapper on top of fetch_foo specifically for this callsite and use the stamina's decorator API

None of these are the end of the world, but it made me wonder if I'd ever use the iterator-based API again :) Has anyone else bumped into this? Is there a way to signal to a type checker that an iterator will definitely yield at least once?

[hynek]

I think I ran into it myself and was rather annoyed – but this is really a Python typing question: is there a way to tell the type checker that an iterator yields at least one value? cc @Tinche 😇

[hynek]

According to Łukasz, this only happens in Pyright’s strict mode? Unfortunately, it’s useless for real-world software IME. :|

[zsol]

Nah, this happens in Pyright's default mode as well as Pyre's. But yeah, mypy doesn't complain even in strict mode:

• mypy (strict)
• pyright
• pyre

[ambv]

I can't reproduce in VScode with

    "python.analysis.typeCheckingMode": "basic",

I need to set it to "strict" for it to complain. This test file:

import stamina

async def g() -> None:
    async for attempt in stamina.retry_context(Exception, 2):
        with attempt:
            foo = 1
    print(foo + 1)

[zsol]

Ah you are right, basic doesn't include reportPossiblyUnboundVariable. But the pyright playground defaults to standard which does include that error (strict too). IDK, basic is a bit too ... basic IMO :) you don't get errors about incompatible overrides, for example. But that's not what this discussion is about

[hynek]

Yeah either way, I'm afraid this is a future typing PEP? :|