Give concurrent.future.Future the right module name

[pelson]

Currently the classes in concurrent.futures give unexpected/internal sub-package names for __str__ of the class:

$ python3 -c "import concurrent.futures as f; print(f.Future)"
<class 'concurrent.futures._base.Future'>

After this change, they get the intended (and documented) location.

This is an aesthetic change to make it easier to correlate an object with its documentation, and does cause a noteworthy issue beyond that.

I did not include the executor implementations in this change as they are implemented in a non-private module. However, the documentation does state that they come from concurrent.futures:

python3 -c "import concurrent.futures as f; print(f.ThreadPoolExecutor)"
<class 'concurrent.futures.thread.ThreadPoolExecutor'>

I did some research, and there are a few occurrences in the CPython implementation of re-defining __module__ in this way (examples include re, abc, and io).

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[pelson]

There is nothing stale about it - it just needs a reviewer. It is a fairly trivial change.

[github-actions]

This PR is stale because it has been open for 90 days with no activity.

[aisk]

Currently there are more classes in this file, eg. InvalidStateError, which don't have __module__ set, so I think this PR is stale (or incomplete) now. And since this is a user visible change, the news entry and issue should not be skipped.

[aisk]

Hi, please avoid force push in the future, see: https://devguide.python.org/getting-started/pull-request-lifecycle/#don-t-force-push

[pelson]

Hi, please avoid force push in the future, see: https://devguide.python.org/getting-started/pull-request-lifecycle/#don-t-force-push

Thanks for letting me know. In this case, I thought the change was relevant to embed into a single commit (and it needed rebasing anyway), but I will be sure to not do this in the future.