-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recommend DateType in the datetime documentation #105563
Comments
can you assign me this?? |
Hi @rakesh9541! Unfortunately there is already an open PR to address this issue: #105946. I would be better to wait until that has been reviewed before opening another one :) |
hauntsaninja
pushed a commit
that referenced
this issue
Sep 1, 2023
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Sep 1, 2023
…onGH-105946) (cherry picked from commit 8f9ea43) Co-authored-by: TATHAGATA ROY <[email protected]>
This was referenced Sep 1, 2023
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this issue
Sep 1, 2023
…onGH-105946) (cherry picked from commit 8f9ea43) Co-authored-by: TATHAGATA ROY <[email protected]>
hauntsaninja
pushed a commit
that referenced
this issue
Sep 1, 2023
Yhg1s
pushed a commit
that referenced
this issue
Sep 2, 2023
this one should be closed? |
yep, the recommendation is definitely there in the docs now |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Documentation
At the PyCon US 2023 sprints, I spent some time with @glyph, @hauntsaninja, @AlexWaygood and others trying to put together a plan to make the type stubs for
datetime
distinguish between naïve and aware datetimes (even if the runtime types don't reflect this). Unfortunately, we came to the conclusion that there's no way to do it in a backwards-compatible way that accounts for subclasses without the use of higher-kinded types (this is not the first time we came to that conclusion, and unfortunately in neither case did we write down the exact reason this is a problem as far as I know, so, uh... let's remember to do that next time we tilt at this particular windmill).Some time ago, however, @glyph did come up with a set of
Protocol
classes that basically solves the problem for anyone who is willing to opt in to it, since that frees him from certain backwards compatibility concerns. The upshot of the conversation was that the best we can do from the CPython side is probably to add a link toDateType
into thedatetime
documentation, presumably in the "See also" infobox, along with a recommendation that it can be used to improve type checking of naïve vs. aware datetimes.I realized that we didn't get around to this in the sprints and we never made an issue to track the progress, so when this recently came up in this issue, it reminded me to open this issue.
CC: @abalkin
Linked PRs
The text was updated successfully, but these errors were encountered: