Hello,

On Fri, 30 Aug 2013 14:51:42 +0200 (CEST)
eli.bendersky <python-checkins@python.org> wrote:
> diff --git a/Doc/library/xml.etree.elementtree.rst b/Doc/library/xml.etree.elementtree.rst
> --- a/Doc/library/xml.etree.elementtree.rst
> +++ b/Doc/library/xml.etree.elementtree.rst
> @@ -105,37 +105,42 @@
> � � >>> root[0][1].text
> � � '2008'
>
> -Incremental parsing
> -^^^^^^^^^^^^^^^^^^^
> +Pull API for asynchronous parsing
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think the documentation should use another term than "asynchronous":
"non-blocking" or "event-driven" would be fine. "Asynchronous" is loaded
with various meanings and connotations which IMO make it the wrong term
here.

For example, in many contexts "asynchronous" means "does the job behind
your back, e.g. in a worker thread". POSIX defines some asynchronous
I/O APIs which are ostensibly not the same as non-blocking I/O:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/aio_read.html

Makes sense. I'll change it to non-blocking, since this doc already uses "blocking" here and there to refer to the opposite effect.
">

(original) (raw)




On Fri, Aug 30, 2013 at 10:07 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:

Hello,

On Fri, 30 Aug 2013 14:51:42 +0200 (CEST)
eli.bendersky <python-checkins@python.org> wrote:
\> diff --git a/Doc/library/xml.etree.elementtree.rst b/Doc/library/xml.etree.elementtree.rst
\> --- a/Doc/library/xml.etree.elementtree.rst
\> +++ b/Doc/library/xml.etree.elementtree.rst
\> @@ -105,37 +105,42 @@
\> � � >>> root\[0\]\[1\].text
\> � � '2008'
\>
\> -Incremental parsing
\> -^^^^^^^^^^^^^^^^^^^
\> +Pull API for asynchronous parsing
\> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I think the documentation should use another term than "asynchronous":
"non-blocking" or "event-driven" would be fine. "Asynchronous" is loaded
with various meanings and connotations which IMO make it the wrong term
here.

For example, in many contexts "asynchronous" means "does the job behind
your back, e.g. in a worker thread". POSIX defines some asynchronous
I/O APIs which are ostensibly not the same as non-blocking I/O:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/aio\_read.html

Makes sense. I'll change it to non-blocking, since this doc already uses "blocking" here and there to refer to the opposite effect.


Eli