[Numpy-discussion] Merge of date-time branch completed

[Travis Oliphant]

On Aug 28, 2009, at 4:03 PM, Charles R Harris wrote:

>
>
> On Fri, Aug 28, 2009 at 2:43 PM, Travis Oliphant <oliphant at enthought.com 
> > wrote:
>
> On Aug 28, 2009, at 12:39 PM, Charles R Harris wrote:
>
>>
>>
>> On Fri, Aug 28, 2009 at 10:47 AM, Travis Oliphant <oliphant at enthought.com 
>> > wrote:
>>
>> Hello folks,
>>
>> In keeping with the complaint that the pace of NumPy development is  
>> too fast, I've finished the merge of the datetime branch to the  
>> core.  The trunk builds and all the (previous) tests pass for me.
>>
>> There are several tasks remaining to be done (the current status is  
>> definitely still alpha):
>>
>> * write many unit tests for the desired behavior  (especially for  
>> the many different kinds of dates supported)
>> * finish coercion between datetimes and timedeltas with different  
>> frequencies
>> * improve the ufuncs that support datetime and timedelta so that  
>> they look at the frequency information.
>> * improve the way datetime arrays print
>> * probably several other things that I haven't listed
>>
>> Because of the last point, I will spend my next effort on the work  
>> updating the proposal to more clearly define some of the expected  
>> behaviors and write documentation about the expected behavior of  
>> the new features.
>>
>> Help, reviews, criticisms, suggestions, fixes, and patches, are  
>> most welcome.
>>
>> Umm, replacing the previous code 'M' by '.'  in generate_umath is a  
>> bit obscure. Isn't there a better choice than '.' ?
>>
>> Please make the multiline comments conform to the standard. I spend  
>> a lot of time fixing these up... And you broke some I already fixed.
>
> Sorry about that.   Can you remind me what the standard is?
>
> /*
>  * blah, blah
>  * blah, blah
>  */
>
> It makes the extent of the comment more blatant, especially if it is  
> a long comment, and separates it from the code. No more looking for  
> that elusive */. For code reading/maintenance blatant is good.
>
> How about 'P' instead of '.' ? I'll guess that 'M' originally stood  
> for method and that's gone, but 'P' follows 'O', which isn't any  
> sort of argument but at least 'P' is easier to see on the page ;)
>

I like it --- was just trying to think of a better one.     Thought of  
'o', but it looks basically the same.


--
Travis Oliphant
Enthought Inc.
1-512-536-1057
http://www.enthought.com
oliphant at enthought.com





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090828/5708084f/attachment.html>