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

Pyright #252

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

Pyright #252

wants to merge 7 commits into from

Conversation

gilesknap
Copy link
Contributor

This PR re-adopts the copier, making sure that pyproject.toml is correct for pyright adoption.

It also has started to fix pyright errors in the source. BUT there seem to be many errors in here that someone with a better understanding of the code should look at.

  • For the moment I have removed the tests from pyright checks - this should also eventually be restored.
  • There are many cases of incompatible function signatures in derived classes that should be properly addressed
  • Also many argument / parameter type disagreements
  • There is too much to even just apply type: ignore to everything at 5PM on Friday and I also don't think that is the right way to go.

@coretl I'll let you decide what to do with this branch, I'm OK to carry on with it next week but imagine it is a few days work to do right.

Copy link
Collaborator

@coretl coretl left a comment

Choose a reason for hiding this comment

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

I think this is worth spending some time one, but I think we should spend half an hour going through the errors in person

Copy link
Collaborator

Choose a reason for hiding this comment

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

These are intentional, so we get reasonable settings without a .vscode dir

Copy link
Contributor Author

Choose a reason for hiding this comment

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

noted. I feel like was set up to fail on this task!

Copy link
Collaborator

Choose a reason for hiding this comment

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

This should also be deleted

Copy link
Contributor Author

Choose a reason for hiding this comment

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

right

from bluesky.callbacks.best_effort import BestEffortCallback
from bluesky.plan_stubs import mov, movr, rd # noqa
from bluesky.plans import grid_scan # noqa
from bluesky.run_engine import RunEngine
Copy link
Collaborator

Choose a reason for hiding this comment

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

Curious why these imports changed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here I was just doing what pyright asked me to - It seemed that it did not like the module level declaration in init.py.

@@ -170,20 +170,20 @@ async def test_mover_disconncted():
with pytest.raises(NotConnected):
async with DeviceCollector(timeout=0.1):
m = demo.Mover("ca://PRE:", name="mover")
assert m.name == "mover"
assert m.name == "mover"
Copy link
Collaborator

Choose a reason for hiding this comment

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

These should be in their original position

Copy link
Contributor Author

Choose a reason for hiding this comment

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

pyright did not like that. it said that m may not be instantiated.
Looking at it again I see that this is not going to behave as required with my change (because the expected exception would jump over final assert)
pyright is correct in that if the DeviceCollector constructor throws NotConnected then m would not be set.

But this is rather pedantic and should probably be ignored.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

or pre declare m.

@gilesknap
Copy link
Contributor Author

I think this is worth spending some time one, but I think we should spend half an hour going through the errors in person

OK lets do this. But you realize 30 mins is less than 18 seconds per issue?

@coretl coretl mentioned this pull request Jul 31, 2024
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