[Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

[Yuriy Taraday]

On Wed, Jan 9, 2013 at 8:50 AM, Guido van Rossum <guido at python.org> wrote:

> On Tue, Jan 8, 2013 at 8:31 PM, Guido van Rossum <guido at python.org> wrote:
> > On Tue, Jan 8, 2013 at 5:14 PM, Yuriy Taraday <yorik.sar at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130109/4f35067a/attachment.html>