On Mon, Apr 20, 2020 at 4:19 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 21/04/20 8:29 am, Eric Snow wrote:
* Would a low-level channel implementation based on callbacks or locks be better (simpler, faster, etc.) than one based on buffering?
Depends on what you mean by "better". Callbacks are more versatile; a buffered channel just does buffering, but with callbacks you can do other things, e.g. hooking into an event loop.
Thanks for clarifying. For the event loop case, what is the downside to adapting to the API in the existing proposal?
* Would readiness callbacks in the high-level API be more or less user-friendly than alternatives: optional blocking, a lock, etc.?
I would consider callbacks to be part of a low-level layer that you wouldn't use directly most of the time. Some user-friendly high-level things such as buffered channels would be provided.
Ah, PEP 554 is just about the high-level API. Currently in the low-level API recv() doesn't ever block (instead raising ChannelEmptyError if empty) and channel_send() returns a pre-acquired lock that releases once the object is received. I'm not opposed to a different low-level API, but keep in mind that we're short on time.
Efficiency is a secondary consideration. If it turns out to be a problem, that can be addressed later.
+1 -eric