python / python/mypy

`TypeGuard` has no effect when nested in the presence of other problems

Open
#17,138 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

Bug Report

A TypeGuard declared and used near the top of a function is sometimes rendered ineffective (i.e., there is no change to the type of the first argument to the TypeGuard even when the TypeGuard returns True), but only when there is an apparently-unrelated mypy-detectable problem later in the same function.

The problem does not occur if the TypeGuard definition is not nested within an outer function, or if the apparently-unrelated problem is corrected.

Because any erroneous errors triggered by this bug appear above the triggering problem in the error report, users will find it difficult to solve this issue if they approach the problem using a [run mypy, fix first issue, repeat] workflow.

To Reproduce

[mypy-play.net]

from __future__ import annotations
from typing_extensions import (
        TypeGuard,
        assert_type,
        )

def some_func(arg: object) -> None:
    '''must encapsulate the following in a func, or issue won't repro
    '''
    def tg_int(arg: object) -> TypeGuard[int]:
        '''must be nested: issue won't repro if decl'd at module scope'''
        b: bool
        return b

    # replacing 'arg' with a local var works just as well
    if tg_int(arg):                                                     # line 16
        assert_type(arg, int)                                           # line 17
                # expected: no error
                # got: [assert-type]
                #   "Expression is of type 'object', not 'int'"

    # this is wrong, but removing it causes the unexpected error to
    # vanish:
    var1 = non_existant_var  # type: ignore[name-defined]

Expected Behavior

The TypeGuard invocation at line 16 should change the type of arg to int when the if statement's condition is truthy. The assert_type() on line 17 should pass.

Actual Behavior

The TypeGuard has no effect on the type of its argument.

Your Environment

  • Mypy version used: 1.9.0, master (as provided by mypy-play.net as of 2024-04-17)
  • Mypy command-line flags: (none necessary)
  • Mypy configuration options from mypy.ini (and other config files): none
  • Python version used: 3.8, 3.12

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked mypy-play.net reproducer and run it against mypy 1.9.0 or master. Investigate why the nested TypeGuard does not narrow arg when the later name-defined error is present; done means the assert_type(arg, int) check passes while the later error remains ignored.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.