GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||||||||
GeezerVison is showing github.com — gh-94597: add asyncio.EventLoop by graingert · Pull Request #110723 · python/cpython Conversation
|
|
This allows running asyncio coroutines without interacting with the policy system eg: asyncio.run(main(), loop_factory=asyncio.EventLoop) # no need to call asyncio.set_event_loop_policy(None) ! this allows code to run without interfering with a policy that has been set in one location especially one that expects |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Do you intend this to be merged before or after the deprecations PR?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| Uses the most efficient available event loop for the given | ||
| platform. |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I think this ought to explain that it's an alias for one of the above classes, and that it's the one used by default, and that it's selected the way described above (L1689-90). "Uses" doesn't even explain that it's a subclass of AbstractEventLoop.
Maybe we should be less specific about how the default is selected, and probably whatever we say about it should be only said once, but it should be made clear that this class is the default, and the default is this class.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
…PC8t.rst Co-authored-by: Guido van Rossum <[email protected]>
| Uses the most efficient available event loop for the given | ||
| platform. |
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
maybe something like this? The other classes don't explain that they are subclasses of AbstractEventLoop, should that be explained in ProactorEventLoop and SelectorEventLoop?
| Uses the most efficient available event loop for the given | |
| platform. | |
| Uses the most efficient available event loop for the given | |
| platform. | |
| It is an alias for :class:`SelectorEventLoop` on Unix and :class:`ProactorEventLoop` on Windows. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Not quite. I don't like any sentence describing a class object starting with "Uses". Classes are nouns, and the description should explain what the class is, not what it does. Also, the current algorithm for choosing a default is now specified in two places. I think it should be specified only here (and the earlier text should be changed to claim that EventLoop is the class used by default).
It's also a good idea to clarify that both concrete classes are subclasses of AbstractEventLoop (but if you're tired of going around in review you can skip that).
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
ok I've pushed a change with some doc tweaks
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
I don't mind what order the PRs go in - I plan a cleanup PR for the CPython test suite removing redundant calls to |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
it's always available
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Merging now.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Well. In the early days of tulip/asyncio, there were more choices, and we didn't know how third-party projects will inherit/override these classes. Now I agree that asyncio.EventLoop is the way to go, it's easier to remind, it's more explicit, and it's easy to guess what is it (SelectorEventLoop or ProactorEventLoop). |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
This is needed to pave the way for deprecating and eventually killing the event loop policy system (which is over-engineered and rarely used).
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.