feat: add support for multiprocessing.resource_sharer type hints

[kkirsche]

X-Ref: #6799

This adds best-effort types to multiprocessing.sharer to continue to address issue #6799

The source file can be viewed here:
https://github.com/python/cpython/blob/main/Lib/multiprocessing/resource_sharer.py

[kkirsche]

Commit history includes all types including private if it helps for review

[AlexWaygood]

Commit history includes all types including private if it helps for review

It doesn't really, to be honest — please delete them :)

[AlexWaygood]

Please remove all the private things

[kkirsche]

Sorry about that, the pre-commit bot's changes prevented the push. Cleaning that up now

Private things were removed

[AlexWaygood]

This all looks like a bit too much to maintain, considering it's a private class in an undocumented module. The only public think here is the stop() callable:

Suggested change

	class _ResourceSharer:
	def __init__(self) -> None: ...
	def register(self, send: Callable[[Connection, int], None], close: Callable[[], None]) -> tuple[_Address, int]: ...
	@staticmethod
	def get_connection(ident: tuple[_Address, int]) -> Connection: ...
	def stop(self, timeout: float | None = ...) -> None: ...
	_resource_sharer: _ResourceSharer = ...
	stop = _resource_sharer.stop
	def stop(timeout: float | None = ...) -> None: ...

[kkirsche]

I understand the point, though personally I think it's valuable to provide these types of things for developers who choose to start doing development on internals in more depth, as without the private methods, for me at least, it really hinders learning the cpython stdlib codebase

[AlexWaygood]

I agree that typeshed is a fantastic tool for learning about the stdlib codebase, but that's ultimately not its primary purpose.

The issue with including implementation details in the stub is that there are no backwards compatibility guarantees, so they're liable to change frequently, possibly even in micro releases of CPython. That just imposes too much of a maintenance burden on us as maintainers.

There's also a question of the usefulness of these implementation details for typechecking. End users of this module shouldn't be using implementation details of this module in their applications or libraries (because they're liable to change at any time), so it's good, in a way, if a typechecker emits an error when a user tries to import one of these implementation details.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉