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

I don't have any opinion really

We should in general type things as the implementation does it, not as documented. I think it applies here too. I also don't see any reason why tests for this function should check with all types that IPv4Network and IPv6Network accept, even though that's the intention; that would make the tests longer without increasing the test coverage.

If someone still feels "uneasy" about this, we could add a test case -- again, nothing too thorough, could be for example the two examples in the issue.

And I just realized that adding a test case to typeshed would be pointless, as those don't run at runtime :) I still think we should support this, because it works.

I still think we should support this, because it works.

I'm fine with this being merged, just don't necessarily want to be the one to hit "merge" myself :)

I agree that in general, we should follow the implementation rather than the documentation.

Passing in a tuple seems to be a common pattern: https://grep.app/search?q=ip_network%28%28

🥳

The discussion here led me to believe that a tuple ip_network argument might be unsupported, so I've looked it up: the two-tuple form for the (ip network) address constructor parameter is documented (supported since Python 3.5) and the corresponding commit has tests too python/cpython@5fb195f

i.e., the two-tuple support won't go away without breaking backward compatibility.