ENH: Expose the condition classes as substitute for the string based conditions #36
Labels
built-in
Relates to the built-in tasks, conditions etc.
documentation
Improvements or additions to documentation
enhancement
New feature or request
Is your feature request related to a problem? Please describe.
The scheduling syntax is easy but it is error-prone and does not work with static code analysis.
For example, this has no highlighting and it is hard to validate before runtime:
The syntax parser turns the strings to the Python instances that represent the conditions but the naming of these conditions is not always the best.
Describe the solution you'd like
Candidate A): use the existing (but maybe think better names):
Candidate B): have similarly named instances as in the string expressions:
These also could be used in generating the condition syntax items instead of the ugly class methods that exist for them.
Additional context
This is related to the part of the library that is quite old and could have some cleaning. The logic of these conditions is based on ideas that evolved into better ones which means the code in this area is not as clear as it could be.
The text was updated successfully, but these errors were encountered: