FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

TypeGuard behavior does not match python semantics in async functions · Issue #19608 · python/mypy · GitHub

Repository navigation

TypeGuard behavior does not match python semantics in async functions #19608

Open

Description

I'm not sure if this should go here or in the mypyc issue tracker. I believe its a bug in mypy itself which only causes notable issues when you compile code with mypyc.

Bug Report

TypeGuard behavior does not match python semantics in async functions. The block which a TypeGuard applies to should end at the next await, assuming the TypeGuard is on an instance attribute or some other mutable nonlocal var.

This causes unnecessary TypeErrors in mypyc-compiled code.

To Reproduce

https://mypy-play.net/?mypy=latest&python=3.12&gist=50cf9499e4e5be34d3faa754bd6052c0

Note: This code snippet does not produce any mypy errors, the bug is only exposed when compiling similar code with mypyc.

Expected Behavior

The TypeGuard should only guarantee the type of self._db up to the next await/async with/async for, because after that point the type is no longer guaranteed.

Actual Behavior

The TypeGuard "guarantees" the type of self._db longer than it is logically able to. Mypyc will raise a TypeError on line 12 if another task sets self._db while our coroutine waits for the lock.

Your Environment

  • Mypy version used: 1.17.0
  • Python version used: 3.12

Activity

  1. changed the title [-][BUG] TypeGuard behavior does not match python semantics in async functions[/-] [+]TypeGuard behavior does not match python semantics in async functions[/+] on Aug 7, 2025
  2. sterliakov commented on Aug 7, 2025

    Collaborator

    I think this is very similar to #17537 - retaining narrowed attribute types is not always safe. The main reason is calling mutating methods between accesses (as in that report), but any await point should also invalidate such narrowing. Unfortunately, we cannot just disable such narrowing of attributes, and tracking mutating methods is difficult.

  3. JelleZijlstra commented on Aug 7, 2025

    Member

    I don't think async code is really special here. Narrowing class attributes is basically never safe, as code that modifies the attribute could be running at any time as a result of a method call, or even code running in another thread. However, narrowing class attributes is very important in practice for making type checkers practically useful, so we shouldn't drop it entirely, though perhaps we can come up with better heuristics to drop the narrowing in some cases where it makes sense.

    For mypyc, this means that we can't rely on the type that was narrowed by a TypeGuard. (Which we already can't, since we don't verify that the TypeGuard's behavior is right.)

  4. JelleZijlstra commented on Aug 7, 2025

    Member

    (Sorry didn't mean to close, my browser suddenly started hanging.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugmypy got something wrongtopic-type-narrowingConditional type narrowing / binder

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL