Message413480
Sure, I'll be glad to work with Andrew on getting something presentable.
Going through the discussion in the issue:
* it seems like folks don't think move_on is useful enough to be in the stdlib, I understand that point. Users can always catch the timeout error from `timeout`, and I can just keep `move_on` in Quattro. We can always add it later. So as far as I'm concerned we can drop it.
* `async with` vs `with`: if Andrew thinks `async with` is easier to teach and less error-prone, I'm ok with having the `async with` civilian version in the stdlib and I can keep the `with` expert versions in Quattro, no problem there.
So I'm most interested in the cancellation semantics, because those will be very hard to fix in a 3rd party package.
@Andrew, in your schema for the third case the behavior is wrong, the `.cancel()` should win over the timeout. Otherwise using the context manager becomes too risky in real-world situations. I also think your first graph has an issue if the user has a `try/except TimeoutError` between `timeout-a` and `timeout-b`, which is now more probable since we're dropping `move_on`. We can take the discussion to the forked repo; I can put together some tests if that would make it easier. |
|
Date |
User |
Action |
Args |
2022-02-18 13:06:10 | tinchester | set | recipients:
+ tinchester, gvanrossum, njs, jab, asvetlov, alex.gronholm, chris.jerdonek, yselivanov, iritkatriel, ajoino |
2022-02-18 13:06:09 | tinchester | set | messageid: <1645189569.97.0.931402286792.issue46771@roundup.psfhosted.org> |
2022-02-18 13:06:09 | tinchester | link | issue46771 messages |
2022-02-18 13:06:09 | tinchester | create | |
|