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

Use equality instead of identity to compare types #533

Merged
merged 1 commit into from
Jul 1, 2024

Conversation

tpoliaw
Copy link
Contributor

@tpoliaw tpoliaw commented Jul 1, 2024

In some cases, possibly when MsgGenerator is defined or imported from
different modules, the types can be equivalent but are not the same
instance. In these cases, the identity check would fail and some plans
would be excluded where they shouldn't be. Using equality checks instead
mean it shouldn't matter where the MsgGenerator type was defined as all
instances should be equal.

In some cases, possibly when MsgGenerator is defined or imported from
different modules, the types can be equivalent but are not the same
instance. In these cases, the identity check would fail and some plans
would be excluded where they shouldn't be. Using equality checks instead
mean it shouldn't matter where the MsgGenerator type was defined as all
instances should be equal.
Copy link

codecov bot commented Jul 1, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.10%. Comparing base (2783092) to head (0424e70).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #533   +/-   ##
=======================================
  Coverage   91.10%   91.10%           
=======================================
  Files          40       40           
  Lines        1787     1787           
=======================================
  Hits         1628     1628           
  Misses        159      159           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tpoliaw
Copy link
Contributor Author

tpoliaw commented Jul 1, 2024

copied from the Jira ticket

RE the acceptance criteria, I don't think the imports need to be changed. I could add tests to check that functions defined with both versions of MsgGenerator are included but given in some cases, the different imports still resolve to the same type, I'm not sure they're going to actually test the failure case.

Copy link
Contributor

@callumforrester callumforrester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for looking at this!

@tpoliaw tpoliaw merged commit 53bdbe2 into main Jul 1, 2024
24 checks passed
@tpoliaw tpoliaw deleted the msggenerator_comparisons branch July 1, 2024 15:18
@DiamondJoseph
Copy link
Contributor

This issue is now extending to equality when deployed on i22.

In [25]: for obj in load_module_all(mod):
    ...:         print(f"{obj.__annotations__['return']}")
    ...: 
collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]
collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]
collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]
collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]
collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]
collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]
collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]
collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]

In [26]: from dodal.common import MsgGenerator as m1

In [27]: m1
Out[27]: collections.abc.Generator[bluesky.utils.Msg, typing.Any, None]

In [28]: from dls_bluesky_core.core import MsgGenerator as m2

In [29]: m2
Out[29]: typing.Generator[bluesky.utils.Msg, typing.Any, NoneType]

In [30]: for obj in load_module_all(mod):
    ...:         print(f"{obj.__annotations__['return'] == m2}")
    ...: 
False
False
False
False
False
False
False
False

In [31]: for obj in load_module_all(mod):
    ...:         print(f"{obj.__annotations__['return'] == m1}")
    ...: 
True
True
True
True
True
True
True
True

In [32]: 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants