-
Notifications
You must be signed in to change notification settings - Fork 5
Improve project structure #15
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
Conversation
Signed-off-by: Leandro Lucarella <[email protected]>
We need to export also these symbols, as they are part of the `Dispatcher` interface: - DispatchEvent - Created - Updated - Deleted Signed-off-by: Leandro Lucarella <[email protected]>
The base class makes the documentation less clear and introduces a class hierarchy that could be error prone given that sub-classes are intended to be used in `match` statements. Signed-off-by: Leandro Lucarella <[email protected]>
These events are used by both the actor module and the top-level module, and we want to expose them publicly only in one place (the top-level module), so we don't confuse the users about where they should import symbols from. Signed-off-by: Leandro Lucarella <[email protected]>
Signed-off-by: Leandro Lucarella <[email protected]>
This makes it more clear that new receivers are created each time the method is called. Signed-off-by: Leandro Lucarella <[email protected]>
This is to follow the current actors naming convention. Signed-off-by: Leandro Lucarella <[email protected]>
Signed-off-by: Leandro Lucarella <[email protected]>
Up for discussion. |
We use `lifecycle_events` and `ready_to_execute` respectively to make it more clear that the former provides events for any kind of dispatch changes, including creates and deletes, and that the later provides dispatches that are ready to be executed. Signed-off-by: Leandro Lucarella <[email protected]>
Split the example in 2, one for events and one for ready to execute processing, and add a match statement to make it more clear how it is intended to be used. Signed-off-by: Leandro Lucarella <[email protected]>
src/frequenz/dispatch/_dispatcher.py
Outdated
dispatch_arrived = dispatcher.updated_dispatches.new_receiver() | ||
dispatch_ready = dispatcher.ready_dispatches.new_receiver() | ||
events = dispatcher.lifecycle_events.new_receiver() | ||
ready = dispatcher.ready_to_execute.new_receiver() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was not happy with the names, I like these more :)
|
||
events_receiver = dispatcher.lifecycle_events.new_receiver() | ||
|
||
async for event in events_receiver: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me think we should also expose the client as dispatcher.client
so the user can react to the events in a meaningful way when they want to update or create a new event as a response
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get this. Why do you need the client?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, anyone who wants to update, delete or create a request needs the client to do so, the high-level API
doesn't offer those things (and I don't see how it could do that better than the client)
Great stuff |
Dispatcher
to its own module_DispatchEventBase
classDispatcher
example in docstringDispatcher
return receiver fetchersDispatchActor
toDispatchingActor
Dispatcher
examplesupdated_dispatches
andready_dispatches