On Mon, Dec 5, 2011 at 8:58 AM, David Cournapeau <courn...@gmail.com> wrote:
> On Sun, Dec 4, 2011 at 9:45 PM, Charles R Harris > <charlesr.har...@gmail.com> wrote: > > > > > We'll see how much interest there is. If it becomes official you may get > > more feedback on features. There are some advantages to having some user > > types in numpy. One is that otherwise they tend to get lost, another is > that > > having a working example or two provides a templates for others to work > > from, and finally they provide test material. Because official user types > > aren't assigned anywhere there might also be some conflicts. Maybe > something > > like an extension types module would be a way around that. In any case, I > > think both rational numbers and quaternions would be useful to have and I > > hope there is some discussion of how to do that. > > I agree that those will be useful, but I am worried about adding more > stuff in multiarray. User-types should really be separated from > multiarray. Ideally, they should be plugins but separated from > multiarray would be a good first step. > I think the object and datetime dtypes should also be moved out of the core multiarray module at some point. The user-type mechanism could be improved a lot based on Martin's feedback after he did the quaternion implementation, and needs further expansion to be able to support object and datetime arrays as currently implemented. I realize it is a bit unfair to have this ready for Geoffray's code > changes, but depending on the timelines for the 2.0.0 milestone, I > think this would be a useful thing to have. Otherwise, if some ABI/API > changes are needed after 2.0, we will be dragged down with this for > years. I am willing to spend time on this. Geoffray, does this sound > acceptable to you ? > A rational type could be added without breaking the ABI, in the same way it was done for datetime and half in 1.6. I think the revamp of the user-type mechanism needs its own NEP design document, because changing it will be a very delicate operation in dealing with how it interacts with the NumPy core, and making it much more programmer-friendly will take a fair number of design iterations. -Mark > > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
