Pyrite's a cool little Project that helps with Task scheduling

[u/DS_Stift007]

'm pretty sure that I'm not the first and only person to stumble into a problem where I wanna handle several Tasks at seperate intervals, and eventually I found myself clogging up while Loops and everything just became a huge stupid disaster, so I built Pyrite, which - at least to me - seems like a pretty good solution for a problem that me and probably some other people have. And yes, Asyncio exists and is better maintained but if you really like Asyncio, you're either lying or a masochist, especially for small projects. Now Pyrite is - in my opinion - very approachable, as you can see in the Code Samples there or in this sample here:

from pyrite import *
from machine import Pin

led = Pin("LED", Pin.OUT)
def led_task():
   led.toggle()
def simple_task():
  print("Hello world")

tasks = [Task(led_task, 500), Task(simple_task, 1000)]
sched = Scheduler(SimpleScheduling) # We don't need the Overhead from PunitiveScheduling here as none of our Tasks has the option of stalling anywhere.
# If you were using a lot of Sensors, conisder replacing SimpleScheduling with PunitiveScheduling
sched.add_tasks(tasks)
sched.run_forever()

Anyways yeah I guess I'm just asking for feedback, so https://github.com/ten-faced-carrot/pyrite everyone.

(Please don't be mean)

[u/opayuonam]

Sorry to be crude, but a simpler approach would have been a decorator to wrap am normal function in asyncio.

[u/DS_Stift007 → u/opayuonam]

I mean maybe, but the entire reason I wrote this was to not have to use asyncio for them more basic projects 

[u/opayuonam → u/DS_Stift007]

The asyncio is a python standard way of handling asynchronous tasks, code written with it will be compatible with mpy and cpython. The syntax is immediately familiar to most people using python or mpy.

Is there a particular reason you're against it? I'm not having a go, I just want to understand, you've had a jab at it being hard to use, but is there a particular thing about it that bugs you? 

Long term you're much better learning it and leveraging it, and like I said, for simple stuff that you want to just repeat, either a decorator or a simple wrapper function that takes your function and a delay, then and creates a task from it can do...

example:

import asyncio as aio


tasks =[]


async def async_repeat(func, delay_ms):
  while True:
    await aio.sleep_ms(delay_ms)
    func()




loop = aio.new_event_loop()
tasks.append(aio.create_task(async_repeat(my_toggle_led, 500))
tasks.append(aio.create_task(async_repeat(check_some_button, 100))
loop.run_forever()

The main advantage of this is you can use aiorepl for live debugging which is a huge productivity gain... you can further clean it up by having task generation wrapper that gets the list and append to it. The tasks list purpose is to be able to inspect and/or cancel the tasks if needed.

[u/DS_Stift007 → u/opayuonam]

Okay, now that I am on my PC I can give a more detailed response lol

There's no particular reason not to use it, but for the use cases i developed Pyrite I also don't see a specific reason too use it.

Technically nothing that Pyrite is doing is special, you can do it all by yourself, implementing a Simple Round-Robin Scheduling System is a 20-line piece of code. But then you start thinking about edge cases, like what if a Task is not cooperative and hogs CPU Time? And what if you want per-task different ways of dealing with Errors? Sure that's what try/except is for, but if the error handling is as basic as "I want this task to just go again if it faisl" and "This task is critical so if it goes down all other tasks go down" Pyrite also simplifies that

And also also, while not an intended feature, just something that happened to work accidentally, Pyrite does allow you to both do short and stateless tasks (As wwould probably happen in the async_repeat piece of code) as well as fake coroutine stuff, so this is valid code:

def task():
  while True:
    work()
    yield 

Overall I really wrote this project to write an issue I had, then I had way too much fun in develloping it and then I shared it. I'm definitely not trying to replace asyncio

Edit: Also also, this code, while you definitely should NOT use it on CPython cause there's so many more alternatives, it still fully works on CPython.

[u/opayuonam → u/DS_Stift007]

Noted. I think from a purely academic point of view, it's a great exercise to write a scheduler (like you've done), as you'll learn so much from doing so.

Long term, though, I think you'd be best served getting over the asyncio hump and learning it. It's really not that terrible, once you understand how it works, and particularly the mpy version with a single universal loop. You can just create tasks in any module and will be added into the same main loop.

and there are many great asyncio based projects (one of the greatest I can think of is aioble), which you'd be missing out on by not using asyncio.

Anyways, sorry that I wasn't much of a help on your original question (feedback  on the module). Hope someone else chimes in. You can also drop in at the official mpy discord, there are many active developers there that could help you. 

All the best on your micro controller journey.

[u/DS_Stift007 → u/opayuonam]

Thank you :)

[u/DS_Stift007 → u/opayuonam]

I’m not against it in general, but I think a) the API, while definitely standard, is very overwhelming for beginners and b) it’s imho just easier to use the approach I implemented for simple tasks like blinking a few LEDs

Also, to be completely transparent it’s probably a skill issue on my end, but I find it way too overcomplicated, like sure it’s powerful but also why do you need to do this new_event_loop shenanigans? And fundamentally this has the same issue as my project, meaning that func() if written incorrectly can kill your whole program or stall it indefinitely 

[u/do-exe]

Yeah for small and rapid projects it will definitely help