Transition table as a ClassVar #6331
Conversation
|
|
||
| return ws | ||
|
|
||
| def set_duration_estimate(self, ts: TaskState, ws: WorkerState) -> float: |
There was a problem hiding this comment.
This is just a cut-paste out of the transitions section, as this is not a transition-specific method
crusaderky
force-pushed
the
transition_table
branch
from
ff1b15e to
3233dee
Compare
| ("ready", "released"): transition_generic_released, | ||
| ("released", "error"): transition_generic_error, | ||
| ("released", "fetch"): transition_released_fetch, | ||
| ("released", "missing"): transition_generic_missing, |
crusaderky
force-pushed
the
transition_table
branch
from
3233dee to
b3ca1a4
Compare
| # { | ||
| # (start, finish): | ||
| # transition_<start>_<finish>( | ||
| # self, ts: TaskState, *args, stimulus_id: str | ||
| # ) -> (recommendations, instructions) | ||
| # } |
distributed/worker.py
Outdated
|
|
||
| start = ts.state | ||
| func = self._transitions_table.get((start, cast(str, finish))) | ||
| func = self.TRANSITIONS_TABLE.get((start, cast(TaskStateState, finish))) |
There was a problem hiding this comment.
nit: Should we generally keep the _ around to mark the transitions table as internal use only, i.e. use _TRANSITIONS_TABLE in both Scheduler and Worker?
distributed/worker.py
Outdated
| # self, ts: TaskState, *args, stimulus_id: str | ||
| # ) -> (recommendations, instructions) | ||
| # } | ||
| TRANSITIONS_TABLE: ClassVar[ |
There was a problem hiding this comment.
Meta question: Do we have any conventions on the ordering of class variable definitions, instance variable declarations, class/instance method definitions, etc?
There was a problem hiding this comment.
Typically class variables -> instance variables -> methods. In this case however the class variable MUST be after the transitions.
There was a problem hiding this comment.
Makes sense, I was just wondering how strict we'd be here, also when it comes to ordering of public/private, class/instance methods. It looks like the rule there is "whatever seems to be a reasonable order/grouping".
There was a problem hiding this comment.
We don't group public and private separately. e.g. typically we put private helper methods next to their public parent methods.
2 participants
__init__methodCC @hendrikmakait