Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit c9d66f0

Browse files
authored
bpo-33649 Polish asyncio docs on queues, protocols, and subproccesses (#9306)
* small clarification * edits to protocols doc * Edit async queue doc
1 parent 5633c4f commit c9d66f0

2 files changed

Lines changed: 25 additions & 26 deletions

File tree

Doc/library/asyncio-protocol.rst

Lines changed: 24 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ abstraction for a socket (or similar I/O endpoint) while a protocol
2929
is an abstraction for an application, from the transport's point
3030
of view.
3131

32-
Yet another view is simply that the transport and protocol interfaces
32+
Yet another view is the transport and protocol interfaces
3333
together define an abstract interface for using network I/O and
3434
interprocess I/O.
3535

@@ -109,7 +109,7 @@ Transports Hierarchy
109109
Interface representing a bidirectional transport, such as a
110110
TCP connection.
111111

112-
The user never instantiates a transport directly; they call a
112+
The user does not instantiate a transport directly; they call a
113113
utility function, passing it a protocol factory and other
114114
information necessary to create the transport and protocol.
115115

@@ -388,7 +388,7 @@ Subprocess Transports
388388
.. method:: SubprocessTransport.get_returncode()
389389

390390
Return the subprocess return code as an integer or :const:`None`
391-
if it hasn't returned, similarly to the
391+
if it hasn't returned, which is similar to the
392392
:attr:`subprocess.Popen.returncode` attribute.
393393

394394
.. method:: SubprocessTransport.kill()
@@ -427,11 +427,10 @@ asyncio provides a set of abstract base classes that should be used
427427
to implement network protocols. Those classes are meant to be used
428428
together with :ref:`transports <asyncio-transport>`.
429429

430-
Subclasses of abstract base protocol classes can implement some or
431-
all methods. All those methods are callbacks: they are called by
430+
Subclasses of abstract base protocol classes may implement some or
431+
all methods. All these methods are callbacks: they are called by
432432
transports on certain events, for example when some data is received.
433-
Base protocol methods are not supposed to be called by anything but
434-
the corresponding transport.
433+
A base protocol method should be called by the corresponding transport.
435434

436435

437436
Base Protocols
@@ -531,7 +530,7 @@ accept factories that return streaming protocols.
531530

532531
Whether the data is buffered, chunked or reassembled depends on
533532
the transport. In general, you shouldn't rely on specific semantics
534-
and instead make your parsing generic and flexible enough. However,
533+
and instead make your parsing generic and flexible. However,
535534
data is always received in the correct order.
536535

537536
The method can be called an arbitrary number of times during
@@ -551,12 +550,12 @@ accept factories that return streaming protocols.
551550

552551
This method may return a false value (including ``None``), in which case
553552
the transport will close itself. Conversely, if this method returns a
554-
true value, closing the transport is up to the protocol. Since the
555-
default implementation returns ``None``, it implicitly closes the
553+
true value, the protocol used determines whether to close the transport.
554+
Since the default implementation returns ``None``, it implicitly closes the
556555
connection.
557556

558557
Some transports such as SSL don't support half-closed connections,
559-
in which case returning true from this method will not prevent closing
558+
in which case returning true from this method will result in closing
560559
the connection.
561560

562561

@@ -581,8 +580,8 @@ Buffered Streaming Protocols
581580
Buffered Protocols can be used with any event loop method
582581
that supports `Streaming Protocols`_.
583582

584-
The idea of ``BufferedProtocol`` is that it allows to manually allocate
585-
and control the receive buffer. Event loops can then use the buffer
583+
The idea of ``BufferedProtocol`` is that it allows manual allocation
584+
and control of the receive buffer. Event loops can then use the buffer
586585
provided by the protocol to avoid unnecessary data copies. This
587586
can result in noticeable performance improvement for protocols that
588587
receive big amounts of data. Sophisticated protocols implementations
@@ -658,10 +657,10 @@ factories passed to the :meth:`loop.create_datagram_endpoint` method.
658657
.. note::
659658

660659
On BSD systems (macOS, FreeBSD, etc.) flow control is not supported
661-
for datagram protocols, because send failures caused by
662-
writing too many packets cannot be detected easily.
660+
for datagram protocols, because it is difficult to detect easily send
661+
failures caused by writing too many packets.
663662

664-
The socket always appears 'ready' and excess packets are dropped; an
663+
The socket always appears 'ready' and excess packets are dropped. An
665664
:class:`OSError` with ``errno`` set to :const:`errno.ENOBUFS` may
666665
or may not be raised; if it is raised, it will be reported to
667666
:meth:`DatagramProtocol.error_received` but otherwise ignored.
@@ -705,8 +704,8 @@ Examples
705704
TCP Echo Server
706705
---------------
707706

708-
TCP echo server using the :meth:`loop.create_server` method, send back
709-
received data and close the connection::
707+
Create a TCP echo server using the :meth:`loop.create_server` method, send back
708+
received data, and close the connection::
710709

711710
import asyncio
712711

@@ -754,8 +753,8 @@ received data and close the connection::
754753
TCP Echo Client
755754
---------------
756755

757-
TCP echo client using the :meth:`loop.create_connection` method, send
758-
data and wait until the connection is closed::
756+
A TCP echo client using the :meth:`loop.create_connection` method, sends
757+
data, and waits until the connection is closed::
759758

760759
import asyncio
761760

@@ -812,8 +811,8 @@ data and wait until the connection is closed::
812811
UDP Echo Server
813812
---------------
814813

815-
UDP echo server using the :meth:`loop.create_datagram_endpoint`
816-
method, send back received data::
814+
A UDP echo server, using the :meth:`loop.create_datagram_endpoint`
815+
method, sends back received data::
817816

818817
import asyncio
819818

@@ -856,8 +855,8 @@ method, send back received data::
856855
UDP Echo Client
857856
---------------
858857

859-
UDP echo client using the :meth:`loop.create_datagram_endpoint`
860-
method, send data and close the transport when we received the answer::
858+
A UDP echo client, using the :meth:`loop.create_datagram_endpoint`
859+
method, sends data and closes the transport when it receives the answer::
861860

862861
import asyncio
863862

@@ -978,7 +977,7 @@ Wait until a socket receives data using the
978977
loop.subprocess_exec() and SubprocessProtocol
979978
---------------------------------------------
980979

981-
An example of a subprocess protocol using to get the output of a
980+
An example of a subprocess protocol used to get the output of a
982981
subprocess and to wait for the subprocess exit.
983982

984983
The subprocess is created by th :meth:`loop.subprocess_exec` method::

Doc/library/asyncio-queue.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -60,7 +60,7 @@ Queue
6060

6161
.. coroutinemethod:: join()
6262

63-
Block until all items in the queue have been gotten and processed.
63+
Block until all items in the queue have been received and processed.
6464

6565
The count of unfinished tasks goes up whenever an item is added
6666
to the queue. The count goes down whenever a consumer thread calls

0 commit comments

Comments
 (0)