On 01/28/2015 12:53 PM, Justin Ross wrote:
When you document Python's send, you're going to have to explain that it
either appends bytes to the current delivery or delegates to whatever the
send behavior happens to be on the passed in object, and then explain how
Message has a send behavior that does X. This is much more complex than it
should be.
And this new behavior is only present in the Python layer. The C-layer
send still just appends bytes. Since at the Python layer people will
rapidly begin to think of send only in terms of sending whole messages
(because that's what the examples will do), they will be surprised when
they attempt the same in C.
To me, it would be much better to have append_some_bytes and send_a_message
as distinct, self-evident operations.
How about this as a compromise:
We change the name of the current send() method to send_bytes() (or
something similar).
We add a new send() method that always expects an object with a send
method on it, taking the sender as an argument. This is really just a
convenience to allow sender.send(message) as well as message.send(sender).
Optionally we can then perhaps allow the special treatment of the
argument to Sender.send() where it is bytes, for one release as a way to
transition. Applications wanting to use that form would be directed by
documentation to use the send_bytes() method.
That we we end up with something that is simple, intuitive yet
extensible, and also have the option to avoid breaking the existing api.
So, as far as the patch under review, this would simply mean adding a
send_bytes() method, and calling that from Message.send() and
(optionally) from Sender.send() if the argument does not have a send
method on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
