As someone who was involved in implementing these, I think they should not
be in builtins if that means they have to be in C.

My argument is from a point of maintainability. Writing them was plenty of
effort in the first place; Josh had written them in idiomatic async Python
in the first place, my contribution was to unroll that to sync Python code,
and then port that to (sync) C code. It was a lot of effort and a lot of
code - several hundred lines and 4(?) new types. The Python code was a few
lines - very readable and likely to be practically as fast. We weren't
writing this in C to speed it up or to make the code better, but because we
*had to*.

Implementing async functionality in C is a pain because to implement an
awaitable type you need not just that awaitable type, but a new type to
represent the iterator that am_await returns. I could imagine having
generic type objects and other helpers for implementing async PyObjects in
C but I don't really envisage anyone doing that; if you want to write async
helpers for Python the best framework is Python.

As Josh can attest I was in two minds while implementing this change; I
argued firstly that having them in the operator module is fine, and later,
that if we want async builtins in general, maybe we could implement them in
Python and freeze them into the binary. We pushed on with the C approach
mostly because we were already 70% done, and this was what Yury asked for,
so it seemed more likely that this would get merged.

But, if we're still discussing whether this should be merged in builtins or
operator, and that dictates whether it is in Python or C, I'm 100% behind
having this code be Python.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VZFDUDH3NIBZX4ADPJ4E7VG2WAWOUBAA/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to