-
Notifications
You must be signed in to change notification settings - Fork 524
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
Provide features to ease static type checking #658
Comments
Thanks! It'd also help if the code would be typed in general |
Thank you for quick responese! I see it now, in my case I am using VScode with mypy and as you mentioned - VSCode does not always consider stub files. Now the issue I'm having (apart from mentioned runtime decorated functions) is related to subclassing from transitions import EventData
from transitions.extensions.asyncio import AsyncTransition
class MyTransition(AsyncTransition):
async def _change_state(self, event_data: EventData) -> None:
if hasattr(event_data.machine, "model_graphs"):
graph = event_data.machine.model_graphs[id(event_data.model)]
graph.reset_styling()
graph.set_previous_transition(self.source, self.dest)
await event_data.machine.get_state(self.source).exit(event_data)
event_data.machine.set_state(self.dest, event_data.model)
event_data.update(getattr(event_data.model, event_data.machine.model_attribute))
await event_data.machine.get_state(self.dest).enter(event_data) with the return type set to
I've tried different return type, e.g. with
This is apart from the rest of the typing issues with missing attributes. Could it be that stub files are outdated? Thank you! |
Hi @sy-be,
they are not outdated but could use improvements. As transitions was initially built rather "duck-ish" and very agnostic towards passed arguments, "post-mortem typing" isn't trivial. Furthermore, it reveals some weaknesses the inheritance approach which heavily relies on overriding has (e.g. sync to async or Liskov substitution principle violations) that are not easy to fix. That's also a good thing but requires some refactoring. I made some minor changes in from transitions.extensions.asyncio import AsyncTransition, AsyncEventData
class MyTransition(AsyncTransition):
async def _change_state(self, event_data: AsyncEventData) -> None: # type: ignore[override]
assert self.dest is not None
if hasattr(event_data.machine, "model_graphs"): # [1]
graph = event_data.machine.model_graphs[id(event_data.model)]
graph.reset_styling()
graph.set_previous_transition(self.source, self.dest)
await event_data.machine.get_state(self.source).exit(event_data)
event_data.machine.set_state(self.dest, event_data.model)
event_data.update(getattr(event_data.model, event_data.machine.model_attribute))
await event_data.machine.get_state(self.dest).enter(event_data) However, I guess that block |
Excellent! Thanks for your input! I like the library a lot, with better typing it'd be even better. Any plans on releasing these changes? I'm working on adding types to a large project and ideally would love to minimise the amount of |
Hi @sy-be,
end of this week. I need to check open issues and see whether there are some major issues to be tackled. features will be postponed to the next release though. |
Since transitions uses runtime decoration quite excessively static type checkers have a hard time to analyse trigger and convenience functions. This has been discussed in previous issues:
Functions decorators or wrapper functions might help here:
Furthermore one could consider a new flag that attempts to create convenience functions that follow common style guides. See for instance #385 where the use of enums result in functions such as
is_ERROR
that most linters will complain about.The text was updated successfully, but these errors were encountered: