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-check...@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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #17741: Rename IncrementalParser and its methods.
On Fri, Aug 30, 2013 at 10:07 AM, Antoine Pitrou solip...@pitrou.netwrote: Hello, On Fri, 30 Aug 2013 14:51:42 +0200 (CEST) eli.bendersky python-check...@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/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #17741: Rename IncrementalParser and its methods.
I still think non-blocking sounds network-related... On Fri, Aug 30, 2013 at 12:23 PM, Eli Bendersky eli...@gmail.com wrote: On Fri, Aug 30, 2013 at 10:07 AM, Antoine Pitrou solip...@pitrou.netwrote: Hello, On Fri, 30 Aug 2013 14:51:42 +0200 (CEST) eli.bendersky python-check...@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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #17741: Rename IncrementalParser and its methods.
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~ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #17741: Rename IncrementalParser and its methods.
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 ___ 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/archive%40mail-archive.com
