5 ms·

> There are a number of valid solutions, several of which may be appropriate to support in Python. This proposal provides a single basic solution: “channels”. U

> There are a number of valid solutions, several of which may be appropriate to support in Python. This proposal provides a single basic solution: “channels”. Ultimately, any other solution will look similar to the proposed one, which will set the precedent. Note that the implementation of Interpreter.run() will be done in a way that allows for multiple solutions to coexist, but doing so is not technically a part of the proposal here. > Regarding the proposed solution, “channels”, it is a basic, opt-in data sharing mechanism that draws inspiration from pipes, queues, and CSP’s channels. > As simply described earlier by the API summary, channels have two operations: send and receive. A key characteristic of those operations is that channels transmit data derived from Python objects rather than the objects themselves. When objects are sent, their data is extracted. When the “object” is received in the other interpreter, the data is converted back into an object owned by that interpreter. https://peps.python.org/pep-0554/#shared-data https://peps.python.org/pep-0554/#shared-data

simonw 4y ago
> Along those same lines, we will initially restrict the types that may be passed through channels to the following: > * None > * bytes > * str > * int > * channels > Limiting the initial shareable types is a practical matter, reducing the potential complexity of the initial implementation. That's a really interesting detail - presumably channels can be passed so you can do callbacks ("reply on this other channel"). I wonder why floats aren't on that list? I know they're more complex than ints, but I would expect they would still end up with a relatively simple binary representation.
- galonk 4y ago
  I don’t know why floats aren’t included, but any float can be easily represented by an int with same bits, or a bytestring, using the struct module to convert between them, so there are clear workarounds.
- saagarjha 4y ago
  Sounds like an oversight…
- nine_k 4y ago
  Passing channels over other channels used to be a reasonably standard trick in Go, IIRC.
- tylercrompton 4y ago
  Fun fact, floats are easier than `int` because `float` has a predictable size.
- JoshTriplett 4y ago
  > That's a really interesting detail - presumably channels can be passed so you can do callbacks ("reply on this other channel"). Callbacks or notifications, yes. I use both patterns quite often.
girvo 4y ago
As someone who uses channels all the time (in Nim) for cross-thread comms, this is pretty exciting. The deep-copy that Nim channels do makes things simpler at the cost of more memory allocations obviously, but even on an ESP32-S3 it's been a great abstraction. Of course I get to cheat and use actual shared memory with FreeRTOS semaphores/mutexes and such when its really required, but having channels as the first-class easy-to-use mechanism is the right move in my opinion (which is worth about as much as you just paid for it, of course)
yeswecatan 4y ago
Any idea what a "channel" actually is/how it is implemented?
- znpy 4y ago
  Wild guess, a double-ended queue guarded by some kind of locking mechanism ?

simonw 4y ago

> Along those same lines, we will initially restrict the types that may be passed through channels to the following: > * None > * bytes > * str > * int > * channels > Limiting the initial shareable types is a practical matter, reducing the potential complexity of the initial implementation. That's a really interesting detail - presumably channels can be passed so you can do callbacks ("reply on this other channel"). I wonder why floats aren't on that list? I know they're more complex than ints, but I would expect they would still end up with a relatively simple binary representation.

galonk 4y ago
I don’t know why floats aren’t included, but any float can be easily represented by an int with same bits, or a bytestring, using the struct module to convert between them, so there are clear workarounds.
saagarjha 4y ago
Sounds like an oversight…
nine_k 4y ago
Passing channels over other channels used to be a reasonably standard trick in Go, IIRC.
tylercrompton 4y ago
Fun fact, floats are easier than `int` because `float` has a predictable size.
JoshTriplett 4y ago
> That's a really interesting detail - presumably channels can be passed so you can do callbacks ("reply on this other channel"). Callbacks or notifications, yes. I use both patterns quite often.

girvo 4y ago

As someone who uses channels all the time (in Nim) for cross-thread comms, this is pretty exciting. The deep-copy that Nim channels do makes things simpler at the cost of more memory allocations obviously, but even on an ESP32-S3 it's been a great abstraction. Of course I get to cheat and use actual shared memory with FreeRTOS semaphores/mutexes and such when its really required, but having channels as the first-class easy-to-use mechanism is the right move in my opinion (which is worth about as much as you just paid for it, of course)

yeswecatan 4y ago

Any idea what a "channel" actually is/how it is implemented?

znpy 4y ago
Wild guess, a double-ended queue guarded by some kind of locking mechanism ?