New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we replace send/receive with some other verbs? #1125
Comments
Note: I was only about 20% convinced this was a good idea when I made the initial post, and after thinking about it some more I'm still only about 30% convinced, but since the number has gone up rather than down I figured we might as well have an issue to make sure it doesn't get forgotten. My biggest hesitations are:
That said, I feel like the best so far is PutChannel.put
GetChannel.get
Channel.put, Channel.get
PutStream.put_all
GetStream.get_any
Stream.put_all, Stream.get_any
get_exactly(...)
get_until(...) ...and so on. I feel like ReadChannel.read
WriteChannel.write
Channel.write, Channel.read
WriteStream.write_all
ReadStream.read_any
Stream.write_all, Stream.read_some (or Stream.read_any)
read_exactly(...)
read_until(...) ...except that we normally think of I guess we could use This also relates to the discussion over how similar streams and channels should be – see #959. If we did rename |
Meh. Yeah, streams are channels of individual bytes, but I don't think of them that way. For me, streams are, well, a sequence of bytes that can be individually chopped up into arbitrary chunks that I write (when buffered) and read back (always). Thus using get/put for the one and read_*/write for the other doesn't feel at all strange to me. In fact I'd avoid using the same name: people would assume |
Yeah, but that's the whole reason I want to use the same verb :-). The conjecture is, maybe people will understand this subtle point if we approach it like:
That could be wrong, or it could that there's another even better way to tackle this common confusion, but this seems like one plausible approach that's also concrete enough to do. |
One distinction that comes to mind: Typical usage of Also: I still hold out some hope that Trio will get a single queue-style object with I'm fine with abbreviating receive to recv; it's easier to spell and shorter to type, but more UNIX-y cryptic and thus probably less user-friendly. I'm not sure how we should weight convenience for long-term users against comprehensibility for newcomers. |
so what about push/pull then? |
I think this will be OK in practice, because generally either you're communicating with someone in-process using a memory buffer, in which case anything you send does immediately show up to be received, or else you're communicating between processes, in which case you can't tell whether it shows up immediately or not. Actually even locally, the only way to tell is through
We'll have this whether we want it or not, because as soon as we implement a bit of basic infrastructure it becomes a trivial one-liner: def open_queue(buffer_size):
return StapledChannel(*open_memory_channel(buffer_size)) And as a bonus, you can still do closure tracking – just write But given how trivial this is, I think (a) we probably don't want to also have a separate I think I'm OK with all that – it does relegate this to an idiom rather than a built-in concept, but that feels about right.
Seems workable too. Trying to come up with reasons that this might be better or worse than put/get:
These all seem pretty minor and go both ways, so it's probably one of those things that's ultimately a matter of taste rather than anything objective. |
Splitting this discussion off from #796, and specifically the subthread starting here
@njsmith:
@smurfix:
@njsmith:
The text was updated successfully, but these errors were encountered: