Re: [Python-Dev] cpython: Issue #17741: Rename IncrementalParser and its methods.
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 Regards Antoine.
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
I still think non-blocking sounds network-related... On Fri, Aug 30, 2013 at 12:23 PM, Eli Bendersky <eliben@gmail.com> wrote:
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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
-- Ryan
On 08/30/2013 06:37 PM, Ryan Gonzalez wrote:
I still think non-blocking sounds network-related...
Sometimes it is. And sometimes it's user-input related, or waiting on a local-pipeline related. But in all cases it means, return whatever is ready, don't block if nothing is ready. -- ~Ethan~
On 8/30/2013 9:37 PM, Ryan Gonzalez wrote:
I still think non-blocking sounds network-related...
But it isn't ;-). Gui apps routinely use event loops and/or threads or subprocesses to avoid blocking on either user input (which can come from keyboard or mouse) and maybe disk operations and calculations. For instance, if it became possible to run the test suite from Idle, it would need to be non-blocking so one could continue to edit while the tests run (15-20 min on my machine, divided by number of cores). -- Terry Jan Reedy
participants (5)
-
Antoine Pitrou -
Eli Bendersky -
Ethan Furman -
Ryan Gonzalez -
Terry Reedy