Unsafe subtype: datetime/date

[m-aciek]

Fixes #9015.

This PR introduces unsafe-subtype error code, which makes mypy check fail for unsafe date and datetime classes inheritance, following @JukkaL's comment in the related issue.

Before:

from datetime import date, datetime

if datetime.now() < date.today():  # passing the type checking
    print("that's a surprise!")

After:

from datetime import date, datetime

if datetime.now() < date.today():  # E: Unsupported operand types for < ("datetime" and "date")
    print("that's a surprise!")

This is Copilot agent's work with my prompts' guidance. I reviewed the produced code. The change includes tests and documentation.

Alternatives considered

• remove the inheritance in the typeshed: Experiment: revert datetime-date inheritance typeshed#15136 (worse as it isn't configurable)

Possible addition

• handling of str/Iterable[str] subtyping is straightforward to add

[sterliakov]

Regarding str vs Iterable[str]: are you sure it's actually a good thing to do? I hate pandas decision to prohibit passing a single string as DataFrame columns, it adds unnecessary friction to quickly creating a one-off dataframe (one has to do columns=list('abc')). Is there a reason to reject passing str as Iterable[str] intentionally? Is it a common source of bugs in some codebase you know/work with?

[sterliakov]

This could be a set, but I'm not sure whether it is actually faster than a single-element list

[m-aciek]

Thank you for the review, I will update and benchmark the list/set for this case tomorrow, having an access to the desktop computer.

Regarding str vs Iterable[str]: are you sure it's actually a good thing to do? I hate pandas decision to prohibit passing a single string as DataFrame columns, it adds unnecessary friction to quickly creating a one-off dataframe (one has to do columns=list('abc')). Is there a reason to reject passing str as Iterable[str] intentionally? Is it a common source of bugs in some codebase you know/work with?

It was originally suggested by @JukkaL and I thought it was a good idea. I personally at least once in the past experienced or seen a bug that could have been prevented with such a check.

But this makes me think that maybe a way to select an unsafe subtyping class may be a good addition, to offer better control for mypy users, to let use only one inheritance pair, instead of covering only all or none.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅