plum: Does not work with future annotations

A resolution error is raised when you make a promise using annotations. It works if you stop importing the annotations package and use quotation marks.

The following code breaks. If you comment out the first line, the code works.

from __future__ import annotations
from plum import dispatch


class Displacement:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    @dispatch
    def __add__(self, other: "Displacement") -> "Displacement":
        return Displacement(self.x + other.x, self.y + other.y)

    @dispatch
    def __add__(self, other: int) -> "Displacement":
        return Displacement(self.x + other, self.y + other)


if __name__ == "__main__":
    d1 = Displacement(1, 2)
    d2 = Displacement(3, 4)
    print(d1 + d2)    

Traceback (most recent call last):
  File "C:\Users\gaspa\dev\python\py-chess\src\geometry_copy.py", line 22, in <module>
    print(d1 + d2)
  File "plum\function.py", line 585, in plum.function._BoundFunction.__call__
  File "plum\function.py", line 509, in plum.function.Function.__call__
  File "plum\function.py", line 373, in plum.function.Function._resolve_pending_registrations
  File "C:\Users\gaspa\.virtualenvs\py-chess-YZvcAOQM\lib\site-packages\plum\type.py", line 436, in is_object
    return t.get_types() == (object,)
  File "C:\Users\gaspa\.virtualenvs\py-chess-YZvcAOQM\lib\site-packages\plum\type.py", line 259, in get_types
    return ptype(self.resolve()).get_types()
  File "C:\Users\gaspa\.virtualenvs\py-chess-YZvcAOQM\lib\site-packages\plum\resolvable.py", line 41, in resolve
    raise ResolutionError(f"Promise `{self!r}` was not kept.")
plum.resolvable.ResolutionError: Promise `ForwardReferencedType(name="'Displacement'")` was not kept.

Process finished with exit code 1

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 39 (19 by maintainers)

Most upvoted comments

Thanks, @gasparyanartur. This is something that will have to be fixed. I imagine that it shouldn’t be too complicated to get right.

@bariod, you’re right! You caught a subtle bug. The bug has the do with the behaviour of @staticmethod, which is different between 3.9 and 3.11. The latest release v2.1.1 should fix the above issue.

@seeM Thanks! Will be solved in the next release.

@PhilipVinc Definitely! I indeed did that along the way of fixing all the bugs. The tests are here.

Awesome, I’ll take a look at it a bit later