On Wed, Jan 9, 2013 at 8:50 AM, Guido van Rossum <guido@python.org> wrote:
On Tue, Jan 8, 2013 at 8:31 PM, Guido van Rossum <guido@python.org> wrote:
> On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday <yorik.sar@gmail.com> wrote:
>> - pause() and resume() work with reading only, so they should be suffixed
>> (prefixed) with read(ing), like pause_reading(), resume_reading().
>
> Agreed.

I think I want to take that back. I think it is more common for a
protocol to want to pause the transport (i.e. hold back
data_received() calls) than it is for a transport to want to pause the
protocol (i.e. hold back write() calls). So the more common method can
have a shorter name. Also, pause_reading() is almost confusing, since
the protocol's method is named data_received(), not read_data(). Also,
there's no reason for the protocol to want to pause the *write* (send)
actions of the transport -- if wanted to write less it should not have
called write(). The reason to distinguish between the two modes of
pausing is because it is sometimes useful to "stack" multiple
protocols, and then a protocol in the middle of the stack acts as a
transport to the protocol next to it (and vice versa). See the
discussion on this list previously, e.g.
http://mail.python.org/pipermail/python-ideas/2013-January/018522.html
(search for the keyword "stack" in this long message to find the
relevant section).

I totally agree with protocol/transport stacking, anyone should be able to do some ugly thing like FTP over SSL over SOCKS over SSL over HTTP (j/k). Just take a look at what you can do with netgraph in *BSD (anything over anything with any number of layers).
But still we shouldn't sacrifice ease of understanding (both docs and code) for couple extra chars (10 actually).
Yes, 'reading' is misleading, pause_receiving and resume_receiving are better.

--

Kind regards, Yuriy.