[Numpy-discussion] code review for datetime arange

[Ralf Gommers]

On Fri, Jun 10, 2011 at 4:18 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:

> On Fri, Jun 10, 2011 at 12:56 AM, Ralf Gommers <
> ralf.gommers at googlemail.com> wrote:
>
>>
>> Maybe I'm misunderstanding this, and once you make a function work for
>> datetime it would also work for other new dtypes. But my impression is that
>> that's not the case. Let's say I make a new dtype with distance instead of
>> time attached. Would I be able to use it with arange, or would I have to go
>> in and change the arange implementation again to support it?
>>
>
> Ok, I think I understand the point you're driving at now. We need NumPy to
> have the flexibility so that external plugins defining custom data types can
> do the same thing that datetime does, having datetime be special compared to
> those is undesirable. This I wholeheartedly agree with, and the way I'm
> coding datetime is driving in that direction.
>
> The state of the NumPy codebase, however, prevents jumping straight to such
> a solution, since there are several mechanisms and layers of such
> abstraction already which themselves do not satisfy the needs of datetime
> and other similar types. Also, arange is just one of a large number of
> functions which could be extended individually for different types, for
> example if one wanted to make a unit quaternion data type for manipulating
> rotations, its needs would be significantly different. Because I can't see
> the big picture from within the world of datetime, and because such
> generalization takes a great amount of effort, I'm instead making these
> changes minimally invasive on the current codebase.
>
> This approach is along the lines of "lifting" in generic programming. First
> you write your algorithm in the specific domain, and work out how it behaves
> there. Then, you determine what are the minimal requirements of the types
> involved, and abstract the algorithm appropriately. Jumping to the second
> step directly is generally too difficult, an incremental path to the final
> goal must be used.
>
> http://www.generic-programming.org/about/intro/lifting.php
>
> Thanks for explaining, this makes sense to me now.

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