[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client
New submission from Jyotirmoy Bhattacharya : 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 urllib, thus breaking the promise in the documentation. I am attaching a test program that demonstrates this bug. -- components: Library (Lib) files: test_urllib_except.py messages: 150849 nosy: jmoy, orsenthil priority: normal severity: normal status: open title: urllib.request.urlopen leaks exceptions from socket and httplib.client versions: Python 3.3 Added file: http://bugs.python.org/file24172/test_urllib_except.py ___ Python tracker <http://bugs.python.org/issue13736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client
Jyotirmoy Bhattacharya 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 type: -> behavior Added file: http://bugs.python.org/file24173/urllib_exception_leak.patch ___ Python tracker <http://bugs.python.org/issue13736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client
Jyotirmoy Bhattacharya 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 clients who only catch URLError based on the documentation. At least one exception which I feel must be wrapped is socket.timeout. Since we allow a timeout argument to urlopen, it doesn't make sense for the fact of the timeout to be announced by an exception from another library. -- ___ Python tracker <http://bugs.python.org/issue13736> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29449] clear() should return prior state in threading.Event
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 and all may try to clear() the event. A return value from clear will indicate to a thread if it won the race to clear the event. -- components: Library (Lib) messages: 287039 nosy: jmoy priority: normal severity: normal status: open title: clear() should return prior state in threading.Event type: enhancement versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue29449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29449] clear() should return prior state in threading.Event
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 who did it. > Here's the scenario that prompted my report: the Event is set to indicate that certain 'work' has accumulated and one among a pool of workers uses clear() to claim the work accumulated till that point. If clear() returned a value, we could easily ensure that only one among the workers woken up actually does the work. Of course, in this case it would be more efficient to wake up just one worker using a Condition object and notify() but then one has to write the logic to maintain the state of the event. An Event whose clear() returned a value would allow for a quick and dirty solution. -- ___ Python tracker <http://bugs.python.org/issue29449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29449] clear() should return prior state in threading.Event
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 <http://bugs.python.org/issue29449> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
