[issue37658] In some cases asyncio.wait_for can lead to socket leak.

Sam Bull added the comment: There is still an issue here. I proposed a possible solution at: https://github.com/python/cpython/pull/28149#issuecomment-1007823782 You can also scroll up through the lengthy discussion to see how I reached that conclusion. I've not had time yet to actually try

[issue46771] Add some form of cancel scopes

Sam Bull added the comment: > We could store the nonces in a single CancelledError instead. Indeed, my initial proposal was exactly that, but after learning about ExceptionGroup, I thought that was a cleaner approach. -- ___ Python trac

[issue46771] Add some form of cancel scopes

Sam Bull added the comment: > Previously, when the task was cancelled twice, only one CancelledError was > raised. Now it would raise a BaseExceptionGroup instead. I was under the impression that ExceptionGroup was somewhat backwards compatible, in that you could still use `

[issue46771] Add some form of cancel scopes

Sam Bull added the comment: Actually, in your counter proposal, you say: > Such context managers should still keep track of whether they cancelled the > task themselves or not, and if they did, they should always call t.uncancel(). But, if we are using nonces on the CancelledError t

[issue46771] Add some form of cancel scopes

Sam Bull added the comment: > This should be solved when using the cancel count -- the explicit cancel > bumps the cancel count so the cancel scope (i.e. timeout()) will not raise > TimeoutError. It will probably work in this case. But, what about more complex cases? If th

[issue46771] Add some form of cancel scopes

Sam Bull added the comment: > If the task is already pending a cancellation targeted at a cancel scope, the > task itself cannot be cancelled anymore since calling cancel() again on the > task is a no-op. This would be solved by updating the cancel message on the > second call

[issue45098] asyncio.CancelledError should contain more information on cancellations

Sam Bull added the comment: I think there's still a problem, in that the user still expects a task to be cancelled in the example previously: https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523 If we encounter the race condition where the timeout cancels the task

[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition

Sam Bull added the comment: It has been addressed, PR should be merged this week: https://github.com/python/cpython/pull/28149 Like most open source projects, it just needed someone to actually propose a fix. -- ___ Python tracker <ht

[issue37658] In some cases asyncio.wait_for can lead to socket leak.

Sam Bull added the comment: Can I get a review? https://github.com/python/cpython/pull/29202 Seems like a simple mistake given the original description of this issue: > 1. the inner task is completed and the outer task will receive the result – > transport and protocol in this ca

[issue37658] In some cases asyncio.wait_for can lead to socket leak.

Change by Sam Bull : -- nosy: +dreamsorcerer nosy_count: 10.0 -> 11.0 pull_requests: +27471 pull_request: https://github.com/python/cpython/pull/29202 ___ Python tracker <https://bugs.python.org/issu

[issue45098] asyncio.CancelledError should contain more information on cancellations

New submission from Sam Bull : There are awkward edge cases caused by race conditions when cancelling tasks which make it impossible to reliably cancel a task. For example, in the async-timeout library there appears to be no way to avoid suppressing an explicit t.cancel

[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition

Change by Sam Bull : -- nosy: +dreamsorcerer nosy_count: 8.0 -> 9.0 pull_requests: +26587 pull_request: https://github.com/python/cpython/pull/28149 ___ Python tracker <https://bugs.python.org/issu

[issue44815] asyncio.gather no DeprecationWarning if task are passed

Change by Sam Bull : -- pull_requests: +26076 pull_request: https://github.com/python/cpython/pull/27569 ___ Python tracker <https://bugs.python.org/issue44

[issue44815] asyncio.gather no DeprecationWarning if task are passed

Sam Bull added the comment: There is another issue with asyncio.sleep() too, if the passed argument is 0. This also tripped up the tests in aiohttp (though I've also used an explicit 0 in production code to yield back to the loop). -- ___ Python

[issue44815] asyncio.gather no DeprecationWarning if task are passed

Change by Sam Bull : -- keywords: +patch pull_requests: +26075 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27568 ___ Python tracker <https://bugs.python.org/issu

[issue44815] asyncio.gather no DeprecationWarning if task are passed

New submission from Sam Bull : When calling asyncio.gather() a DeprecationWarning is only emitted if no tasks are passed (which is probably the exceptional case, rather than the standard one). This has resulted in us missing this deprecated argument in aiohttp until we received a bug report

[issue43404] No SSL certificates when using the Mac installer

New submission from Sam Bull : After installing the latest version of Python on Mac OS X using the installer downloaded from python.org (https://www.python.org/ftp/python/3.9.2/python-3.9.2-macosx10.9.pkg), the installed version of Python is unable to find the system certificates. Using

[issue33315] Allow queue.Queue to be used in type annotations

Change by Sam Bull : -- nosy: +dreamsorcerer ___ Python tracker <https://bugs.python.org/issue33315> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38364] inspect.iscoroutinefunction / isgeneratorfunction / isasyncgenfunction can't handle partialmethod objects

Change by Sam Bull : -- nosy: +dreamsorcerer ___ Python tracker <https://bugs.python.org/issue38364> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40563] Support pathlike objects on dbm/shelve

Change by Sam Bull : -- nosy: +dreamsorcerer ___ Python tracker <https://bugs.python.org/issue40563> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33618] Support TLS 1.3

Change by Sam Bull : -- nosy: +dreamsorcerer ___ Python tracker <https://bugs.python.org/issue33618> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36484] Can't reorder TLS 1.3 ciphersuites

Change by Sam Bull : -- nosy: +dreamsorcerer ___ Python tracker <https://bugs.python.org/issue36484> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8797] urllib2 basicauth broken in 2.6.5: RuntimeError: maximum recursion depth exceeded in cmp

Sam Bull s...@pocketuniverse.ca added the comment: I think there's a much simpler solution to this ticket than the retry logic that's currently in place. The code originally avoided the infinite recursion by checking to see if the previous request had already submitted the auth credentials