[Numpy-discussion] numpy 2.0, what else to do?

David Cournapeau cournape at gmail.com
Mon Feb 15 17:34:24 EST 2010


On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau <cournape at gmail.com>
> wrote:
>>
>> On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>>
>> >
>> > I was wondering about that. Why do we have a private include directory?
>> > Would it make more sense to move it to core/include/numpy/private.
>>
>> No, the whole point is to avoid other packages to include that by
>> mistake, to avoid namespace pollution.
>
> Isn't that what the npy prefix is for?

No, npy_ is for public symbols. Anything in private should be private :)

> In any case, if it needs to be at a
> higher level for easy inclusion, then it should move up.

It is not that easy - we should avoid putting this code into
core/include, because then we have to keep it compatible across
releases, but there is no easy way to share headers between modules
without making it public.

That's one of the numerous issues of having numpy/scipy organized as a
multiple set of independent packages (even though they are not
independent).

> Or else all the c
> code should move down. Having a mix of obj_ptr->ob_type and Py_TYPE(obj_ptr)
> is just asking for trouble. Mindless consistency is the safest policy in
> such things.

Maybe npy_3kcompat.h could be copied across the modules which need it.
I will look into distutils to check whether there is an easy way to
add an include path from one package to the other, but since Pauli
said it was complicated, I am not that hopeful.

David



More information about the NumPy-Discussion mailing list