Instead of trying to fix the PyPi version, I can write a proof of concept of what I described above?
That would definitely be useful, and would help us get a more solid idea of
what exactly is being proposed. I also agree that a potential version
contained in the select module should be as simple as possible and rather
low-level (more so than the linked PyPI project), as it's likely going to
be there primarily for building other tools with. There's no guarantee of
course that it will ultimately be accepted, but a proof of concept
implementation would be a highly productive first step, IMO.
On Tue, Jun 16, 2020 at 2:58 PM
I've looked over the PyPi version of `eventfd`, and I feel that it is trying to be more than just a thin wrapper. The attempt to make it cross platform has given it more fields than it requires, as has the attempt to wrap it as a semaphore, and with that comes added complexity.
The `eventfd` that I was suggesting be added would in my mind look something more like this:
`eventfd`: - `__init__(...)` - `read(...)` - `write(...)` - `close(...)` - `closed(...)` - `fileno(...)` + some extra dunder methods
We could possibly add a method to get the flags that were passed to `__init__`, and I think pickling should be disabled (while it does get inherited through `fork(2)` and likely through `execve(2)` depending on flags, I think the fd's integer value in each process can be different, though I could be wrong here).
From that, one could then build more complex classes, but the base primitive should be as simple as possible. Instead of trying to fix the PyPi version, I can write a proof of concept of what I described above?
doodspav _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/62XBNI... Code of Conduct: http://python.org/psf/codeofconduct/