Adding c-api async protocol support
A type slot for tp_as_async has already been added (which is good!) but we do not currently seem to have protocol functions for awaitable types. I would expect to find an Awaitable Protocol listed under Abstract Objects Layer, with functions like PyAwait_Check, PyAwaitIter_Check, and PyAwaitIter_Next, etc. Specifically its currently difficult to test whether an object is awaitable or an awaitable iterable, or use said objects from the c-api without relying on method testing/calling mechanisms.
Arc Riley schrieb am 25.06.2015 um 04:36:
A type slot for tp_as_async has already been added (which is good!) but we do not currently seem to have protocol functions for awaitable types.
I would expect to find an Awaitable Protocol listed under Abstract Objects Layer, with functions like PyAwait_Check, PyAwaitIter_Check, and PyAwaitIter_Next, etc.
Specifically its currently difficult to test whether an object is awaitable or an awaitable iterable, or use said objects from the c-api without relying on method testing/calling mechanisms.
FYI, Cython's latest master branch already implements PEP 492 (in Python 2.6+, using slots in Py3.2+). So you can just write "await x" and "async for ..." and get the expected slot calling code for it, or method calling fallback code in Python 2.x. That being said, I guess you're right that CPython would eventually want to extend the C-API here in order to cover the new protocols also for manually written C code. I'd wait with that a bit, though, until after Py3.5 is finally released and the actual needs for C code that want to use the new features become clearer. Stefan
On Wed, Jun 24, 2015 at 9:48 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
I'd wait with that a bit, though, until after Py3.5 is finally released and the actual needs for C code that want to use the new features become clearer.
I strongly disagree. What we would end up with is 3rd party extension modules developed over the next 2-3 years including their own awaitable testing functions/macros, and in order to continue to provide 3.5 support into the future that code will persist for the next 5-10 years regardless to whether its later added in Python 3.6.
Hi Arc, On 2015-06-24 10:36 PM, Arc Riley wrote:
A type slot for tp_as_async has already been added (which is good!) but we do not currently seem to have protocol functions for awaitable types.
I would expect to find an Awaitable Protocol listed under Abstract Objects Layer, with functions like PyAwait_Check, PyAwaitIter_Check, and PyAwaitIter_Next, etc.
Specifically its currently difficult to test whether an object is awaitable or an awaitable iterable, or use said objects from the c-api without relying on method testing/calling mechanisms.
The request is reasonable, I created a couple of bug tracker issues: http://bugs.python.org/issue24511 http://bugs.python.org/issue24510 Let's continue the discussion there. Yury
It looks like the code is currently moving fast. I suggest to wait until Python 3.6 to stabilize the Python C API for async/await. It's a pain to maintain a public API. I hate having to add 2 or 3 versions of a single function :-( Victor 2015-06-25 17:43 GMT+02:00 Yury Selivanov <yselivanov.ml@gmail.com>:
Hi Arc,
On 2015-06-24 10:36 PM, Arc Riley wrote:
A type slot for tp_as_async has already been added (which is good!) but we do not currently seem to have protocol functions for awaitable types.
I would expect to find an Awaitable Protocol listed under Abstract Objects Layer, with functions like PyAwait_Check, PyAwaitIter_Check, and PyAwaitIter_Next, etc.
Specifically its currently difficult to test whether an object is awaitable or an awaitable iterable, or use said objects from the c-api without relying on method testing/calling mechanisms.
The request is reasonable, I created a couple of bug tracker issues:
http://bugs.python.org/issue24511 http://bugs.python.org/issue24510
Let's continue the discussion there.
Yury
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...
I'm with Victor: we are in beta now. Making C API is useful and important but we may wait for new Python release. The same for asycnio acceleration: we definitely need it but it requires inviting C API also I believe. Personally I've concentrated on making third-party libraries on top of asyncio -- aiohttp etc. P.S. Thank you Victor so much for your work on asyncio. Your changes on keeping source tracebacks and raising warnings for unclosed resources are very helpful. On Thu, Jun 25, 2015 at 6:56 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
It looks like the code is currently moving fast. I suggest to wait until Python 3.6 to stabilize the Python C API for async/await. It's a pain to maintain a public API. I hate having to add 2 or 3 versions of a single function :-(
Victor
2015-06-25 17:43 GMT+02:00 Yury Selivanov <yselivanov.ml@gmail.com>:
Hi Arc,
On 2015-06-24 10:36 PM, Arc Riley wrote:
A type slot for tp_as_async has already been added (which is good!) but we do not currently seem to have protocol functions for awaitable types.
I would expect to find an Awaitable Protocol listed under Abstract Objects Layer, with functions like PyAwait_Check, PyAwaitIter_Check, and PyAwaitIter_Next, etc.
Specifically its currently difficult to test whether an object is awaitable or an awaitable iterable, or use said objects from the c-api without relying on method testing/calling mechanisms.
The request is reasonable, I created a couple of bug tracker issues:
http://bugs.python.org/issue24511 http://bugs.python.org/issue24510
Let's continue the discussion there.
Yury
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.co...
-- Thanks, Andrew Svetlov
Hi, 2015-06-25 19:25 GMT+02:00 Andrew Svetlov <andrew.svetlov@gmail.com>:
P.S. Thank you Victor so much for your work on asyncio. Your changes on keeping source tracebacks and raising warnings for unclosed resources are very helpful.
Ah! It's good to know. You're welcome. We can still enhance the source traceback by building it using the traceback of the current task. Victor
For one time, while we are in a congratulations tunnel, thank you a lot AsyncIO core devs: Since several months, we've pushed on production an average of 2 daemons based on AsyncIO in my company with several protocols. Most of the time there are small daemons, however, some are complex. For now, the AsyncIO toolbox is pretty stable and predictive, especially for the debugging. The maturity is better that I've excepted, especially when you list the AsyncIO ecosystem: We are for now few developers to use that for "concrete" applications. At least to me, it's the best proof that the foundations are good. We should now try to publish more tutorials/examples to attract more newcomers, but I'm the first guilty: I'm completely lack of time to do that. BTW, I hope that EuroPython will be a good event to propagate some good vibes around AsyncIO. -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/ 2015-06-25 22:24 GMT+02:00 Victor Stinner <victor.stinner@gmail.com>:
Hi,
2015-06-25 19:25 GMT+02:00 Andrew Svetlov <andrew.svetlov@gmail.com>:
P.S. Thank you Victor so much for your work on asyncio. Your changes on keeping source tracebacks and raising warnings for unclosed resources are very helpful.
Ah! It's good to know. You're welcome.
We can still enhance the source traceback by building it using the traceback of the current task.
Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/gmludo%40gmail.com
participants (6)
-
Andrew Svetlov -
Arc Riley -
Ludovic Gasc -
Stefan Behnel -
Victor Stinner -
Yury Selivanov