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

ENH: Expose the condition classes as substitute for the string based conditions #36

Closed
Miksus opened this issue Jul 5, 2022 · 1 comment · Fixed by #44
Closed

ENH: Expose the condition classes as substitute for the string based conditions #36

Miksus opened this issue Jul 5, 2022 · 1 comment · Fixed by #44
Labels
built-in Relates to the built-in tasks, conditions etc. documentation Improvements or additions to documentation enhancement New feature or request

Comments

@Miksus
Copy link
Owner

Miksus commented Jul 5, 2022

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:

@app.task("daily between 12:00 and 15:00 & time of week on Monday ")
def do_daily():
    ...

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):

@app.task(TaskExecutable(period=TimeOfDay("12:00", "15:00") & IsPeriod(period=TimeOfWeek("Mon", "Mon"))))
def do_daily():
    ...

Candidate B): have similarly named instances as in the string expressions:

@app.task(daily.between("12:00", "15:00") & time_of_week.on("Monday"))
def do_daily():
    ...

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.

@Miksus Miksus added documentation Improvements or additions to documentation enhancement New feature or request built-in Relates to the built-in tasks, conditions etc. labels Jul 5, 2022
@Miksus
Copy link
Owner Author

Miksus commented Jul 5, 2022

@Miksus Miksus linked a pull request Jul 10, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
built-in Relates to the built-in tasks, conditions etc. documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant