[Numpy-discussion] fixing up datetime

Ralf Gommers ralf.gommers at googlemail.com
Wed Jun 1 17:10:55 EDT 2011


On Wed, Jun 1, 2011 at 11:04 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Wed, Jun 1, 2011 at 3:01 PM, Ralf Gommers <ralf.gommers at googlemail.com>wrote:
>
>>
>>
>> On Wed, Jun 1, 2011 at 10:05 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
>>
>>> Hey all,
>>>
>>> So I'm doing a summer internship at Enthought, and the first thing they
>>> asked me to look into is finishing the datetime type in numpy. It turns out
>>> that the estimates of how complete the type was weren't accurate, and to
>>> support what the NEP describes required generalizing the ufunc type
>>> resolution system. I also found that the date/time parsing code (based on
>>> mxDateTime) was not robust, producing something for almost any arbitrary
>>> garbage input. I've replaced much of the broken code and implemented a lot
>>> of the functionality, and thought this might be a good point to do a pull
>>> request on what I've got and get feedback on the issues I've run into.
>>>
>>> * The existing datetime-related API is probably not useful, and in fact
>>> those functions aren't used internally anymore. Is it reasonable to remove
>>> the functions, or do we just deprecate them?
>>>
>>
>> If the existing API is really not useful (which requires some
>> discussion/review I guess) then I think it would be good to announce that on
>> the mailing list and throw it out ASAP. The API can't have many users yet,
>> since it has only just been released (again), so the sooner it's gone the
>> better. I know normal policy would be to deprecate first, but I don't really
>> see the point.
>>
>>
> +1
>
>
>> And after the removal of datetime from 1.4.1 and now this, I'd be in favor
>> of putting a large "experimental" sticker over the whole thing until further
>> notice.
>>
>>
> Do we have a good way to do that?
>
> Not a perfect one, but if there would be a prominent note in all related
docs that would help a lot already. A more intrusive way would be to raise
warnings.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110601/4931314b/attachment.html>


More information about the NumPy-Discussion mailing list