On Tue, Oct 13, 2015 at 10:48 AM, Stephan Hoyer <sho...@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.bar...@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
