Jyotirmoy Bhattacharya added the comment:
Thanks for the comments above. I'm going to rethink my design. Closing this bug.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.pytho
Jyotirmoy Bhattacharya added the comment:
> > A return value from clear will indicate to a thread if it
> > won the race to clear the event.
>
> Why would we care who won the race to clear? I would think that the
> important thing is that the event is cleared, not
New submission from Jyotirmoy Bhattacharya:
The clear() method for Event objects currently does not return anything.
It would be useful to have it return the state of the Event prior to it being
cleared.
This would be useful since multiple threads may wake up from an event at the
same time
Jyotirmoy Bhattacharya jyotir...@jyotirmoy.net added the comment:
Antoine, could raise ... from be used here? Perhaps also using new subclasses
of URLError to allow the exceptions to be caught with finer granularity. That
way no information would be lost while at the same time not surprising
New submission from Jyotirmoy Bhattacharya jyotir...@jyotirmoy.net:
The documentation for urlopen says that it raises URLError on error.
But there exist error conditions such as a socket timeout or a bad HTTP status
line under which the exception from the underlying library leaks through
Jyotirmoy Bhattacharya jyotir...@jyotirmoy.net added the comment:
A patch to fix this issue. Catches exceptions from underlying libraries and
reraises them as URLError.
I put the class name of the underlying exception in the reason to make it more
descriptive.
--
keywords: +patch
