This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Decorater
Recipients Decorater, gvanrossum, yselivanov
Date 2016-11-30.01:52:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1480470778.51.0.100994440264.issue28836@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2016-11-30 01:52:58Decoratersetrecipients: + Decorater, gvanrossum, yselivanov
2016-11-30 01:52:58Decoratersetmessageid: <1480470778.51.0.100994440264.issue28836@psf.upfronthosting.co.za>
2016-11-30 01:52:58Decoraterlinkissue28836 messages
2016-11-30 01:52:56Decoratercreate