On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris <charlesr.har...@gmail.com > wrote:
> > > On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau <courn...@gmail.com>wrote: > >> On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris >> <charlesr.har...@gmail.com> wrote: >> > >> > >> > On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau <courn...@gmail.com> >> > wrote: >> >> >> >> On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris >> >> <charlesr.har...@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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
