Path to integrate DateType into the standard library

[m-aciek]

Would it be possible to keep the Python's runtime behaviour as is, adding the DateType typing annotations into the standard library “as native”?

To have it accepted we would need to:

• find a PEP sponsor,
• write a PEP,
• draft a CPython pull request.

Did I miss something? Does it sound feasible?

[glyph]

I think this would be an uphill battle, and I am not willing to take it on myself. It is probably possible, but the stdlib obviously has a heavy burden of compatibility. I think that a necessary step that you are leaving out here is popularizing DateType to the point where it becomes clear that this is the behavior the broader community wants. And I don't think we're there yet: https://pypistats.org/packages/datetype

However, I do think that something like this should be done, and I'd love to obsolete DateType if we can get this behavior from the stdlib, so if someone else will take point on the effort (doing each of the 3 steps that you have outlined) I am happy to provide whatever support from my end to make it easier, and possibly collaborate on some of it.

[mttbernardini]

From my DateType-alike experiment, I'm thinking that we could get an almost-native feeling without having to change any of the existing datetime semantics (hence 100% backwards compatible) by "simply":

• Having python implementations implement a dummy __class_getitem__ for datetime and time for the sake of not breaking runtime (which is currently the biggest pain of my datetypes experiment)
• Potentially define all type information in https://github.com/python/typeshed, rather than shipping it into the stdlib

Both, or at least the first point, may require a PEP to ensure all python implementations (e.g. PyPy) behave consistently, but ideally the scope of the PEP could be reduced since no runtime difference would be introduced and typing could be left as add-on (totally following the spirit of type annotations).

I think that a necessary step that you are leaving out here is popularizing DateType to the point where it becomes clear that this is the behavior the broader community wants

@m-aciek A starting point could be to open a discussion in https://discuss.python.org/c/ideas/6 and see if there's any feedback at all? I know at least pydantic has its own type hints and validators for indicating timezone-aware datetimes, so some use cases for this definitely exist, it may just be the information is too scattered at the moment (and I'm to blame too with my datetypes approach, which I'd love to see deprecated/merged eventually).

[m-aciek]

I agree that bringing this topic to the Python forum is a good idea.

The plan for the Python Discourse forum post I was thinking about would be roughly:

• showing that date type is currently unsafe in the typed Python (plus showing that timezone aware/non-aware datetimes are unsafe?),
• discussing available workaround strategies (including solutions available in third party packages) for date/datetime inheritance,
  • using datetime only, even for date context,
  • introducing isinstance checks at API level,
  • mention potential future solution in typing: we would need Not along with Intersection (still being drafted): date & ~datetime
  • DateType, datetypes, whenever, pydantic
• (plus workaround strategies for non-/aware datetimes?)
  • isinstance checks,
  • DateType, datetypes, whenever, pydantic
• short discussion of datetime/date inheritance use cases (showing that number of use cases is very limited), and an ask if I'm missing something,
• stating that in my opinion the fix
  • should be available without third-party packages
  • and shouldn't modify the Python's runtime behaviour,
• presenting available options:
  • removing the inheritance from typeshed, (plus adding generics for (non-)timezone-aware datetimes?),
  • @mttbernardini's __class_getitem__ approach
• if we decide to remove inheritance from typeshed
  • is a PEP required for that?
  • is it possible to deprecate inheritance before removing it?
• ask for opinions

Things I'm not sure about:

• should we include timezone awareness of datetimes in the discussion, or try to focus only on the date inheritance problem?

What do you think?

PS I’m progressing slowly with this topic and don’t consider myself a typing expert, so if you have time for taking the lead in posting it on the Python Discourse forum, please feel free to do so.

[mttbernardini]

@m-aciek Nice writeup. Unfortunately I'm pretty low in bandwidth, and I think you covered more aspects than I could imagine, so feel free to lead on this ;)

For the sake of clarity (I've seen some topics on the Python forum getting confusing when they conflate related concepts), it may be worth creating two separate discussions for aware/naive and date/datetime-inheritance.

[m-aciek]

Trivia: mypy primer for when we would revert the date inheritance from datetime in the typeshed: python/typeshed#15136 (comment)

[glyph]

@m-aciek I don't know how comprehensive the primer is, but that looks like an encouragingly limited blast radius?

[m-aciek]

Agreed 👍 Only 10 out of 157 projects in the primer are impacted by the change.

[m-aciek]

By the way on the topic of naive/aware datetimes: Sebastian Rittau recently finished work on a PR to type datetime as generic over timezone info python/typeshed#11844.

I've made an attempt with Copilot to make a PR to mypy with the flag to warn about unsafe date/datetime inheritance, and I've published it. I think that is better approach than changing typeshed in this regard, due to backwards compatibility with some esotheric code people may have.