[Numpy-discussion] numpy 2.0, what else to do?
Charles R Harris
charlesr.harris at gmail.com
Mon Feb 15 22:36:41 EST 2010
On Mon, Feb 15, 2010 at 8:13 PM, David Cournapeau <david at silveregg.co.jp>wrote:
> Charles R Harris wrote:
> >
> >
> > On Mon, Feb 15, 2010 at 3:58 PM, Charles R Harris
> > <charlesr.harris at gmail.com <mailto:charlesr.harris at gmail.com>> wrote:
> >
> >
> >
> > On Mon, Feb 15, 2010 at 3:34 PM, David Cournapeau
> > <cournape at gmail.com <mailto:cournape at gmail.com>> wrote:
> >
> > On Tue, Feb 16, 2010 at 7:04 AM, Charles R Harris
> > <charlesr.harris at gmail.com <mailto:charlesr.harris at gmail.com>>
> > wrote:
> > >
> > >
> > > On Mon, Feb 15, 2010 at 2:46 PM, David Cournapeau
> > <cournape at gmail.com <mailto:cournape at gmail.com>>
> > > wrote:
> > >>
> > >> On Tue, Feb 16, 2010 at 4:08 AM, Charles R Harris
> > >> <charlesr.harris at gmail.com
> > <mailto: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)
>
> The rule is easy: one should put in core/include/numpy whatever is
> public, and put in private what is not.
>
> Note that defining those macros above publicly is very likely to cause
> trouble because I am sure other people do define those macros, without
> caring about polluting the namespace as well. Given that it is
> temporary, and is small, I think copying the compat header is better
> than making it public, the best solution being to add something in
> distutils to share it between submodules,
>
>
You would prefer to fix the macros in ndarrayobject.h using #ifdef's then?
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100215/31aff323/attachment.html>
More information about the NumPy-Discussion
mailing list