On 8 March 2017 at 04:15, Ethan Furman <ethan at stoneleaf.us> wrote: > On 03/07/2017 09:41 AM, Brett Cannon wrote: > > I don't think a common practice has bubbled up yet for when there's both >> synchronous and asynchronous versions of an API >> (closest I have seen is appending an "a" to the async version but that >> just looks like a spelling mistake to me most of >> the time). This is why the question of whether separate modules are a >> better idea is coming up. >> > > I'm undoubtedly going to show my ignorance with this question, but is it > feasible to have both sync and async support in the same object? > As Jelle says, it depends on the API. For contextlib, we've already decided that 'asynccontextmanager' and 'AsyncExitStack' are going to be parallel APIs, as even though they *could* be the same object, they're much easier to document if they're separate, and you get a form of "verb agreement" at both definition time and at runtime that lets us be confident of the developer's intent. For simpler APIs like "closing" though, I'm leaning more towards the "just make it work everywhere" approach, where the async protocol methods use "await obj.aclose()" if the latter is defined, and a synchronous "obj.close()" otherwise. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170308/1c331142/attachment-0001.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4