Skip to content

pow float return value is Any in 0.950 #7733

Closed

Description

@TylerYep

Bug Report

I upgraded to mypy 0.950 today and ran into the following error involving function return types:

To Reproduce

# x.py
def fn(x: float = 8.9) -> float:
    return 2 ** x    # error: Returning Any from function declared to return "float"  [no-any-return]

Expected Behavior

Expected this to pass cleanly.

Actual Behavior

I'm not sure why this now returns Any.

Your Environment

  • Mypy version used: 0.950
  • Mypy configuration options from mypy.ini (and other config files): strict = True
  • Python version used: Python 3.10.0
  • Operating system and version: Mac OSX

Activity

  1. TylerYep commented on Apr 28, 2022

    @TylerYep
    Author
  2. changed the title [-]pow float return value is Any?[/-] [+]Incompatible return types (Any, object)[/+] on Apr 28, 2022
  3. changed the title [-]Incompatible return types (Any, object)[/-] [+]Incompatible return types (Any, object) errors in 0.950[/+] on Apr 28, 2022
  4. AlexWaygood commented on Apr 28, 2022

    @AlexWaygood
    Member

    Could you open a separate issue about the second thing? It looks like a completely different problem.

    Issue number 1 looks like a pretty clear consequence of #7047 (cc. @JelleZijlstra). We might be able to make the types more specific by adding yet another overload to int.__pow__ or float.__rpow__. I can create a PR in the morning.

  5. changed the title [-]Incompatible return types (Any, object) errors in 0.950[/-] [+]pow float return value is Any in 0.950[/+] on Apr 28, 2022
  6. transferred this issue frompython/mypyon Apr 28, 2022
  7. Akuli commented on Apr 28, 2022

    @Akuli
    Collaborator

    int ** float can be a complex number, if the int is negative.

    >>> (-1) ** 2.3
    (0.587785252292474+0.8090169943749468j)
    

    But this doesn't happen for 2 ** float, or for any other positive number instead of 2:

    >>> 2 ** (-3.4)
    0.09473228540689989
    

    0 ** float behaves a bit surprisingly, and I don't think we should handle it specially in the stubs. In practice, the 0 is very unlikely to be specified in a way where the type checker can infer its type to be Literal[0].

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions