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 tas
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
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
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
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 `
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
Sam Bull 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 that would b
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 actuall
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
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
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).
--
___
P
Change by Sam Bull :
--
pull_requests: +26076
pull_request: https://github.com/python/cpython/pull/27569
___
Python tracker
<https://bugs.python.org/issue44
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
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() if that
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
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 case
&g
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
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 the
Change by Sam Bull :
--
nosy: +dreamsorcerer
___
Python tracker
<https://bugs.python.org/issue36484>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Sam Bull :
--
nosy: +dreamsorcerer
___
Python tracker
<https://bugs.python.org/issue33618>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Sam Bull :
--
nosy: +dreamsorcerer
___
Python tracker
<https://bugs.python.org/issue40563>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Sam Bull :
--
nosy: +dreamsorcerer
___
Python tracker
<https://bugs.python.org/issue38364>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Sam Bull :
--
nosy: +dreamsorcerer
___
Python tracker
<https://bugs.python.org/issue33315>
___
___
Python-bugs-list mailing list
Unsubscribe:
23 matches
Mail list logo