[Numpy-discussion] Deprecating unitless timedelta64 and "safe" casting of integers to timedelta64

[Chris Barker]

On Tue, Oct 13, 2015 at 10:48 AM, Stephan Hoyer <shoyer at gmail.com> wrote:

> This led to my discovery that NumPy currently supports unit-less
> timedeltas (e.g., "np.timedelta64(5)"), which indicate some sort of generic
> time difference. The current behavior is to take the time units from the
> other argument when these are used in a binary operation.
>

this really is odd :-)


> Even worse, we currently support "safe" casting of integers to
> timedelta64, which means that integer + datetime64 and integer +
> timedelta64 arithmetic works:
>

which makes the above even odder -- underlying datetime64 is, "just" a 64
bit int -- so I can see how someone _may_ want to work directly with that
-- but if you can use regular integerts, why have a unitless timedelta?

Based on the principle that NumPy's datetime support should mirror the
> standard library as much as possible, both of these behaviors seem like a
> bad idea. We have datetime types precisely to disambiguate these sort of
> situations.
>
> I'd like to propose deprecating such casting in NumPy 1.11, with the
> intent of removing it entirely as soon as practical.
>

Agreed -- I can imagine use-cases, but users can cadt to/from integers if
that's what they want to do e.g. with .astype()

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151013/9a90707b/attachment.html>