python / python/mypy

Strange custom type for `__init__` behaviour [@curry plugin]

Open
#8,801 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question topic-plugins
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

  • Are you reporting a bug, or opening a feature request?

Bug report / support question.

  • Please insert below the code you are checking with mypy,
    or a mock-up repro if the source is private. We would appreciate
    if you try to simplify your case to a minimal repro.

I am working on @curry typed decorator support. https://github.com/dry-python/returns/pull/350
It works fine for all cases right now. Except for the case when __init__ method is curried.
In this particular case it changes our correct return type (returned from our custom plugin) to some strange incorrect type.

from returns.curry import curry

class Test(object):
    @curry
    def __init__(self, a: int, b: str) -> None:
        ...

    @curry
    def some(self, a: int, b: str) -> None:
        ...

t: Test

# Works fine!
reveal_type(t.some)
# => Revealed type is 'Overload(def () -> Overload(def (a: builtins.int, b: builtins.str), def (a: builtins.int) -> def (b: builtins.str)), def (a: builtins.int) -> def (b: builtins.str), def (a: builtins.int, b: builtins.str))'

# Modifies the return type from our plugin.
reveal_type(Test)
# => Revealed type is 'Overload(def () -> ex.Test, def (a: builtins.int) -> ex.Test, def (a: builtins.int, b: builtins.str) -> ex.Test)'

Full reproduction:

  1. Clone https://github.com/dry-python/returns/pull/350
  2. poetry install
  3. Drop the code from this issue into ./ex.py
  4. poetry run mypy ex.py
  • What is the actual behavior/output?

Let's focus on the incorrect output we are getting for __init__ methods:

reveal_type(Test)
# => Revealed type is 'Overload(def () -> ex.Test, def (a: builtins.int) -> ex.Test, def (a: builtins.int, b: builtins.str) -> ex.Test)'
  • What is the behavior/output you expect?

I expect it to have the exact same type our plugin produces:

Overload(def (self: ex.Test) -> Overload(def (a: builtins.int, b: builtins.str), def (a: builtins.int) -> def (b: builtins.str)), def (self: ex.Test, a: builtins.int) -> def (b: builtins.str), def (self: ex.Test, a: builtins.int, b: builtins.str))

The thing is this type is produced for both .some() and __init__ methods in this example. But, __init__ does change it for some reason. And .some() works correctly.

  • What are the versions of mypy and Python you are using?
    Do you see the same issue after installing mypy from Git master?
  • mypy: 0.770
  • any python from 3.6 to 3.8
  • What are the mypy flags you are using? (For example --strict-optional)

Full list: https://github.com/dry-python/returns/blob/master/setup.cfg#L101

Useful links:

  1. Failing CI with the helpful error message: https://github.com/dry-python/returns/runs/666196191?check_suite_focus=true#step:7:660
  2. Failing typetest source: https://github.com/orsinium-forks/returns/blob/curry/typesafety/test_curry/test_curry/test_curry_arguments.yml#L20
  3. Implementation: https://github.com/orsinium-forks/returns/blob/curry/returns/curry.py#L38
  4. Plugin source: https://github.com/orsinium-forks/returns/blob/curry/returns/contrib/mypy/decorator_plugin.py#L116
  5. Upstream: https://github.com/dry-python/returns

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

Reproduce the issue with the linked returns pull request: install it with Poetry, save the example as ex.py, and run poetry run mypy ex.py. Read returns/curry.py, returns/contrib/mypy/decorator_plugin.py, and the linked curry typetest to compare __init__ with some. Done means the Test type retains the plugin-produced curried signature rather than the incorrect constructor overload.

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
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.