New submission from Decorater: So, concurrent.futures.TimeoutError subclasses concurrent.futures.__base.TimeoutError. Why not have asyncio throw that instead of the __base class for Timeout Error?
There is a huge issue with this for starters for those know knows this they cannot handle it easily without having to use that private class in the Error handler which is totally unclean practice. It is also unclean to raise that exception in asyncio at least change it to concurrent.futures.TimeoutError or asyncio.TimeoutError. This change would be much beneficial for projects that has to handle as many exceptions as possible to tell the end user that an exception happens custom based on what was thrown. With this it could benefit everyone who use the parts of asyncio that can throw such exceptions. I hope you guys would agree with my idea to clean up the parts of asyncio that throws these as it becomes tricky if people don't like to use private functions of another python code file in the standard library in their code or even as little as possible. It happens in python versions from 3.4 to 3.5.2 and can get annoying. ---------- components: Library (Lib), asyncio messages: 282057 nosy: Decorater, gvanrossum, yselivanov priority: normal severity: normal status: open title: Throw concurrent.futures.TimeoutError instead of concurrent.futures.__base.TimeoutError versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28836> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
