> One way to deal with that would be to let a Task have a Future.
> "Prefer composition over inheritance" as they say.
> 
> I want to work on PR for this if nobody goes against it...

I'm not against it, unless it doesn't have backward incompatibility
or performance regression.

But I'm not sure you estimate the difficulty correctly: there are C implementation of Future and Task.  You need to have deep knowledge of Python/C APIs.


> PS: I really don't like when some people says that Python core developers are known to have poor knowledge in regard to OOP principles. So I really don't like letting something like this in the standard library...

Personally speaking, I dislike treating OOP principles like Ten Commandments.  Principles have some reasons.  And these reasons are reasonable not for all cases.  When people say "it's bad because it violates principle!", they may have poor knowledge about the prinicple.
If they really know the principle, they must describe real-world problem caused by the violation.

In this case, I agree that misleading docstring is a small real-world problem caused by the violation.  While it can be fixable without fixing the violation.

Generally, `set_result` or `set_exception` is called by the creator of the Future.  So requiring knowledge of concrete class is not a big problem.
On the other hand, awaiting future object without knowing concrete class is common.  But Task is awaitable.  So there are no problem here.