On Tue, Apr 21, 2020 at 11:21 PM Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > What I'm suggesting is that close() should do what the > PEP defines release() as doing, and release() shouldn't > exist. > > I don't see why an interpreter needs the ability to close > a channel for any *other* interpreter. There is no such > ability for files and pipes.
Ah, thanks for clarifying. One of the main inspirations for the proposed channels is CSP (and somewhat relatedly, my in-depth experience with Go). Channels are more than just a thread-safe data transport between interpreters. They also provide relatively straightforward mechanisms for managing cooperation in a group of interpreters. Having a distinct "close()" vs. "release()" is part of that. Furthermore, IMHO "release" is better at communicating the per-interpreter nature than "close". "release()" doesn't close the channel. It communicates that that particular interpreter is done using that end of the channel. I appreciate that you brought up comparisons with other objects and data types. I'm a fan of adapting existing APIs and patterns, especially from proven sources. That said, the comparison with files would be more complete if channels were persistent. With pipes the main difference is how many actors are involved. Pipes involve one sender and one receiver, right? FWIW, I also looked at other data types. Queues are the closest thing to the proposed channels, and I almost called them that, but there are a few subtle differences from queue.Queue and I didn't want folks inadvertently confusing the two. -eric _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DUVEROBVGZPNKR3M7C45C3AUVDLAGK37/ Code of Conduct: http://python.org/psf/codeofconduct/
