Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(🐞) False except contains Any when inside a function that references a variable that is defined after the function and has an inferred type #13167

Closed
KotlinIsland opened this issue Jul 17, 2022 · 1 comment · Fixed by #13575
Labels
bug mypy got something wrong topic-disallow-any The disallow-any-* family of flags

Comments

@KotlinIsland
Copy link
Contributor

def f():
    a
    try:
        pass
    except Exception as ex:  # error: Expression has type "Any"  [misc]
        pass


a = 1 + 1

playground

@KotlinIsland
Copy link
Contributor Author

Related to #8900

Michael0x2a added a commit to Michael0x2a/mypy that referenced this issue Sep 1, 2022
This diff:

- Fixes python#8129
- Fixes python#13043
- Fixes python#13167

For more concise repros of these various issues, see the modified
test files. But in short, there were two broad categories of errors:

1.  Within the deferred pass, we tend to infer 'Any' for the types of
    different variables instead of the actual type. This interacts
    badly with our unreachable and disallow-any checks and causes
    spurious errors.

    Arguably, the better way of handling this error is to only collect
    errors during the final pass. I briefly experimented with this
    approach, but was unable to find a clean, efficient, and
    non-disruptive way of implementing this. So, I settled for
    sprinkling in a few more `not self.current_node_deferred` checks.

2.  The 'self.msg.disallowed_any_type(...)` call is normally guarded
    behind a `not self.chk.current_node_deferred` check. However, we
    were bypassing this check for `except` block assignments because
    we were deliberately setting that flag to False to work around some
    bug. For more context, see python#2290.

    It appears we no longer need this patch anymore. I'm not entirely
    sure why, but I'm guessing we tightened and fixed the underlying
    problem with deferred passes some time during the past half-decade.
Michael0x2a added a commit to Michael0x2a/mypy that referenced this issue Sep 2, 2022
This diff:

- Fixes python#8129
- Fixes python#13043
- Fixes python#13167

For more concise repros of these various issues, see the modified
test files. But in short, there were two broad categories of errors:

1.  Within the deferred pass, we tend to infer 'Any' for the types of
    different variables instead of the actual type. This interacts
    badly with our unreachable and disallow-any checks and causes
    spurious errors.

    Arguably, the better way of handling this error is to only collect
    errors during the final pass. I briefly experimented with this
    approach, but was unable to find a clean, efficient, and
    non-disruptive way of implementing this. So, I settled for
    sprinkling in a few more `not self.current_node_deferred` checks.

2.  The 'self.msg.disallowed_any_type(...)` call is normally guarded
    behind a `not self.chk.current_node_deferred` check. However, we
    were bypassing this check for `except` block assignments because
    we were deliberately setting that flag to False to work around some
    bug. For more context, see python#2290.

    It appears we no longer need this patch anymore. I'm not entirely
    sure why, but I'm guessing we tightened and fixed the underlying
    problem with deferred passes some time during the past half-decade.
hauntsaninja pushed a commit that referenced this issue Sep 2, 2022
…#13575)

This diff:

- Fixes #8129
- Fixes #13043
- Fixes #13167

For more concise repros of these various issues, see the modified test files. But in short, there were two broad categories of errors:

1.  Within the deferred pass, we tend to infer 'Any' for the types of different variables instead of the actual type. This interacts badly with our unreachable and disallow-any checks and causes spurious errors.

    Arguably, the better way of handling this error is to only collect errors during the final pass. I briefly experimented with this
    approach, but was unable to find a clean, efficient, and non-disruptive way of implementing this. So, I settled for sprinkling in a few more `not self.current_node_deferred` checks.

2.  The `self.msg.disallowed_any_type(...)` call is normally guarded behind a `not self.chk.current_node_deferred` check. However, we were bypassing this check for `except` block assignments because we were deliberately setting that flag to False to work around some bug. For more context, see #2290.

    It appears we no longer need this patch anymore. I'm not entirely sure why, but I'm guessing we tightened and fixed the underlying problem with deferred passes some time during the past half-decade.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong topic-disallow-any The disallow-any-* family of flags
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants