Make `Select.ready()` an async iterable about frequenz-channels-python HOT 4 CLOSED

This will be probably dropped because of the issues mentioned in:

• #27 (comment).

from frequenz-channels-python.

I was just reading about the Select implementation in go again, and realized that when there are multiple receivers ready, it picks one at random, and doesn't allow us to prioritize.

Now that I've thought about it further, I think that's how it should be, and is the true async way. So maybe we should revisit the ideas in #27.

I feel it might be useful to look into what other languages do as well.

Does that make sense?

from frequenz-channels-python.

I am not sure why would we want to not allow the user to prioritize what to process first if there are multiple receivers ready. 🤔

If it is some sort of safety (prevent starvation), maybe that should be an option?

async for receiver in select.one_by_one():
    if receiver is x:
        pass

In any case (I mean if we went with a one receiver at the time) I would still prefer to offer an async iterator interface rather than the less pythonic while loop.

We could decide which one should be default, but removing options from the user doesn't seem like a good idea to me.

About looking at other languages, sure!

from frequenz-channels-python.

OK, now that I went though your new comments in the PR I have a better feeling for the starving issue and I think I'm starting to lean towards reviving #27 too. I created a new issue about that:

• #72

from frequenz-channels-python.