DOC: Document datetime and timedelta to python's object type conversion #29557
Conversation
There was a problem hiding this comment.
While you're at it, I still think adding a new section that describes what NaT is is worth doing. But this is fine to merge without that. It looks much better with the table and code examples!
Maybe @rossbar is interested in looking this over from a documentation editing point of view?
0098596 to
cb016cd
Compare
| Converting datetime and timedelta to Python Object | ||
| ================================================== | ||
|
|
||
| NumPy follows a strict protocol when converting `datetime64` and/or `timedelta64` to Python Objects (e.g., ``tuple``, ``list``, `datetime.datetime`). |
There was a problem hiding this comment.
The cases where .item() returns a tuple or list are pretty rare in practice, so if you need examples, then I'd go with more common python types like float or str.
There was a problem hiding this comment.
I just get to know that for python types like str, int, float it returns np.str_, np.int64 and np.float64. I guess we should stick with examples like tuple, list, and datetime.datetime and explicitly mention the behavior with types like str, int, and float.
There was a problem hiding this comment.
for python types like
str,int,floatit returnsnp.str_,np.int64andnp.float64.
Can this be seen as a bug? Since it should be expected to convert them to Python objects.
Co-authored-by: Joren Hammudoglu <jhammudoglu@gmail.com>
The need to document
datetimeandtimedeltato Python object type conversions arose during a discussion in issue #29516NumPy follows a strict type conversion protocol when converting datetime64 or timedelta64 to standard Python objects. The rules are as follows:
Conversion of datetime64 to Python objects
Conversion of timedelta64 to Python objects
Currently, this behavior is not clearly documented, which can lead to ambiguity for end users, forcing them to infer the conversion rules through experimentation.