[Numpy-discussion] NumPy re-factoring project
Charles R Harris
Thu Jun 10 08:43:52 CDT 2010
On Thu, Jun 10, 2010 at 7:26 AM, Charles R Harris <email@example.com
> On Wed, Jun 9, 2010 at 5:27 PM, Jason McCampbell <
> firstname.lastname@example.org> wrote:
>> Hi everyone,
>> This is a follow-up to Travis's message on the re-factoring project from
>> May 25th and the subsequent discussion. For background, I am a developer at
>> Enthought working on the NumPy re-factoring project with Travis and Scott.
>> The immediate goal from our perspective is to re-factor the core of NumPy
>> into two architectural layers: a true core that is CPython-independent and
>> an interface layer that binds the core to CPython.
>> A design proposal is now posted on the NumPy developer wiki:
>> The write-up is a fairly high-level description of what we think the split
>> will look like and how to deal with issues such as memory management. There
>> are also placeholders listed as 'TBD' where more investigation is still
>> needed and will be filled in over time. At the end of the page there is a
>> section on the C API with a link to a function-by-function breakdown of the
>> C API and whether the function belongs in the interface layer, the core, or
>> need to be split between the two. All functions listed as 'core' will
>> continue to have an interface-level wrapper with the same name to ensure
>> All of this, particularly the interface/core function designations, is a
>> first analysis and in flux. The goal is to get the information out and
>> elicit discussion and feedback from the community.
> A few thoughts came to mind while reading the initial writeup.
> 1) How is the GIL handled in the callbacks.
> 2) What about error handling? That is tricky to get right, especially in C
> and with reference counting.
> 3) Is there a general policy as to how the reference counting should be
> handled in specific functions? That is, who does the reference
> 4) Boost has some reference counted pointers, have you looked at them? C++
> is admittedly a very different animal for this sort of application.
> I've thought that PyArray_SetNumericOps, PyArray_SetNumericOps should have
getter/setter functions so that the structure doesn't have to be made public
in the split up files.
Can the casting functions be implemented as ufuncs? Or at least look like
ufuncs so they can handle strided memory. Likewise for some of the other
things in arraytypes.c.src.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion