DOC: update datetime documentation to explain that "NaT" also requires specific unit#31282
Conversation
[skip actions] [skip cirrus] [skip azp]
|
|
||
| Previously, `datetime64` allowed `NaT` without specifying a time unit. | ||
| With the deprecation of generic units, `NaT` is now required to have an explicit time unit for consistency with other datetime and timedelta operations. | ||
|
|
There was a problem hiding this comment.
Be nice to break the long lines here and elsewhere. You need hard linebreaks.
There was a problem hiding this comment.
Thank you for the review! I've updated them accordingly.
[skip actions] [skip cirrus] [skip azp]
| for consistency with other datetime and timedelta operations. | ||
|
|
||
| >>> np.datetime64("NAT") | ||
| DeprecationWarning: The 'generic' unit for NumPy timedelta is deprecated, and will raise an error in the future. This includes implicit conversion of bare integers (e.g. `+ 1`).Please use a specific unit instead. |
There was a problem hiding this comment.
AI suggests you can break this like so:
>>> np.datetime64("NAT")
DeprecationWarning: The 'generic' unit for NumPy timedelta is deprecated, ... Please use a specific unit instead.
I don't know if that works. We should probably fix the warning text.
There was a problem hiding this comment.
I left it as is because this is inside a code snippet.
When I tried to break the lines, the documentation ended up like below, so the line breaks appear as is.
Would you prefer line breaks even inside a code snippet, or should I keep it?
There was a problem hiding this comment.
AI suggested shortening the output line using elipses ... for missing text. I don't know if it works, but maybe worth a try to find out. No, I wouldn't break the line.
There was a problem hiding this comment.
Thanks for the clarification.
I tried it locally, but I’m not sure if it improves the situation because it still doesn't fit one page width
Anyway, if you prefer, I am happy to push the changes.
There was a problem hiding this comment.
If it works, we can always shorten the line more. I assume it worked? That is good to know. I'll put this in and you can make another PR if the improvement looks good. I think we could break it right after the elipses. It is just an example, if it occurs in the wild the user will see the whole thing.
Strictly speaking, it would be better to put some line breaks in the emitted warning message.
|
Do the tests for the deprecation capture these cases? |
|
Yes, I think so. The tests below capture the deprecation warnings numpy/numpy/_core/tests/test_deprecations.py Lines 439 to 441 in 388bd75 |
ngoldbaum
left a comment
There was a problem hiding this comment.
LGTM, thanks for following through on this @riku-sakamoto
|
Thanks @riku-sakamoto . |
PR summary
This is a follow-up PR based on the comment #31213 (comment)
Thank you for pointing it out! @lucascolley
AI Disclosure
I used ChatGPT to improve the English wording in this commit 3720a77 .