[Python-Dev] API design: where to add async variants of existing stdlib APIs? (original) (raw)
Guido van Rossum guido at python.org
Mon Mar 6 21:08:51 EST 2017
- Previous message (by thread): [Python-Dev] API design: where to add async variants of existing stdlib APIs?
- Next message (by thread): [Python-Dev] API design: where to add async variants of existing stdlib APIs?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Mar 6, 2017 at 5:57 PM, Raymond Hettinger < raymond.hettinger at gmail.com> wrote:
Of course, it makes sense that anything not specific to asyncio should go outside of asyncio.
What I'm more concerned about is what the other places actually are. Rather than putting async variants of everything sprinkled all over the standard library, I suggest collecting them all together, perhaps in a new asynctools module.
That's a tough design choice. I think neither extreme is particularly attractive -- having everything in an asynctools package might also bundle together thing that are entirely unrelated. In the extreme it would be like proposing that all metaclasses should go in a new "metaclasstools" package. I think we did a reasonable job with ABCs: core support goes in abc.py, support for collections ABCs goes into the collections package (in a submodule), and other packages and modules sometimes define ABCs for their own users.
Also, in some cases I expect we'll have to create a whole new module instead of updating some ancient piece of code with newfangled async variants to its outdated APIs.
-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170306/299d8eba/attachment.html>
- Previous message (by thread): [Python-Dev] API design: where to add async variants of existing stdlib APIs?
- Next message (by thread): [Python-Dev] API design: where to add async variants of existing stdlib APIs?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]