Yes, I think that would be a lot better. On Wed, Jan 28, 2015 at 11:00 AM, Gordon Sim <[email protected]> wrote:
> 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] > >
