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

[Charles R Harris]

On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau <cournape at gmail.com>wrote:
>
>> 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.
>>
>>
> Py_TYPE, Py_Size, etc. are unlikely to cause compatibility problems across
> releases.
>
>

In particular, I think

#if (PY_VERSION_HEX < 0x02060000)
#define Py_TYPE(o)    (((PyObject*)(o))->ob_type)
#define Py_REFCNT(o)  (((PyObject*)(o))->ob_refcnt)
#define Py_SIZE(o)    (((PyVarObject*)(o))->ob_size)
#endif

belongs somewhere near the top, maybe with a prefix (cython seems to define
them also)

Chuck

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100215/7f372c3f/attachment.html>