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

David Cournapeau david at silveregg.co.jp
Mon Feb 15 22:13:33 EST 2010


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,

cheers,

David



More information about the NumPy-Discussion mailing list