[Numpy-discussion] code review for datetime arange
Thu Jun 9 16:54:43 CDT 2011
On Thu, Jun 9, 2011 at 4:27 PM, Ralf Gommers <firstname.lastname@example.org>wrote:
> On Thu, Jun 9, 2011 at 10:58 PM, Mark Wiebe <email@example.com> wrote:
>> On Thu, Jun 9, 2011 at 3:41 PM, Christopher Barker <Chris.Barker@noaa.gov
>> > wrote:
>> Your branch works fine for me (OS X, py2.6), no failures. Only a few
> deprecation warnings like:
> DeprecationWarning: DType strings 'O4' and 'O8' are deprecated because they
> are platform specific. Use 'O' instead
> callableObj(*args, **kwargs)
It looks like there are some '|O4' dtypes in 'lib/tests/test_format.py',
testing the .npy file format. I'm not sure why I'm not getting this warning
> Mark Wiebe wrote:
>>> > Because of the nature of datetime and timedelta, arange has to be
>>> > slightly different than with all the other types. In particular, for
>>> > datetime the primary signature is np.arange(datetime, datetime,
>>> > I've implemented a simple extension which allows for another way to
>>> > specify a date range, as np.arange(datetime, timedelta, timedelta).
>>> Did you think about how to document which of these basic functions work
> with datetime? I don't think that belongs in the docstrings, but it may then
> be hard for the user to figure out which functions accept datetimes. And
> there will be no usage examples in the docstrings.
I think documenting it in a 'datetime' section of the arange documentation
would be reasonable. The main datetime documentation page would also mention
the functions that are most useful.
Besides docs, I am not sure about your choice to modify functions like
> arange instead of writing a module of wrapper functions for them that know
> what to do with the dtype. If you have a module you can group all relevant
> functions, so they're easy to find. Plus it's more future-proof - if at some
> point numpy grows another new dtype, just create a new module with wrapper
> funcs for that dtype.
The facts that datetime and timedelta are related in a particular way
different from other data types, and that they are parameterized types, both
contribute to them not fitting naturally the current structure of NumPy. I'm
not sure I understand the module idea, I would rather think that since it's
a built-in NumPy data type, it should work with the regular NumPy functions
wherever that makes sense. The implementation can also be changed in the
future without affecting the behavior of the function, since it's the
semantics which are most important. The experience hooking in datetime and
timedelta can guide future abstraction to more general dtype mechanisms.
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion