On Thu, 24 Sep 2015 00:20:23 -0700
Nathaniel Smith wrote:
> > int PyUFunc_Identity(PyFuncObject *)
> >
> > Replaces ufunc->identity.
>
> Hmm, I can imagine cases where we might want to change how this works.
> (E.g. if np.dot were a ufunc then the existing identity settings
> wouldn't work very
On Tue, Sep 22, 2015 at 7:57 AM, Antoine Pitrou wrote:
>
> Hi,
>
> This e-mail is an attempt at proposing an API to solve Numba's needs.
Thanks!
> Attribute access
>
>
> int PyUFunc_Nin(PyUFuncObject *)
>
> Replaces ufunc->nin.
>
> int PyUFunc_Nout(PyUFuncObject *)
>
> Repla
On Tue, Sep 22, 2015 at 10:19 PM, Nathaniel Smith wrote:
> On Tue, Sep 22, 2015 at 3:43 PM, Charles R Harris
> wrote:
> >
> >
> > On Mon, Sep 21, 2015 at 10:23 PM, Nathaniel Smith wrote:
> [...]
> >> When it comes to evolving these APIs in general: one unfortunate thing
> >> about the PyArrayOb
On Tue, Sep 22, 2015 at 3:43 PM, Charles R Harris
wrote:
>
>
> On Mon, Sep 21, 2015 at 10:23 PM, Nathaniel Smith wrote:
[...]
>> When it comes to evolving these APIs in general: one unfortunate thing
>> about the PyArrayObject changes in 1.7 is that because they were
>> implemented using *inline*
That sounds like a very good idea. I know that one of the original
motivations for the odd import mechanism of NumPy was the AIX platform and
it's lack of a shared library.I can't imagine that is still actually a
problem.
A simpler, library-based mechanism would be a welcome change from my
p
On Tue, Sep 22, 2015 at 3:43 PM, Charles R Harris wrote:
>
>
> On Mon, Sep 21, 2015 at 10:23 PM, Nathaniel Smith wrote:
>
>> On Mon, Sep 21, 2015 at 7:29 AM, Jaime Fernández del Río
>> wrote:
>> > We have the PyArrayObject vs PyArrayObject_fields definition in
>> > ndarraytypes.h that is used t
On Mon, Sep 21, 2015 at 10:23 PM, Nathaniel Smith wrote:
> On Mon, Sep 21, 2015 at 7:29 AM, Jaime Fernández del Río
> wrote:
> > We have the PyArrayObject vs PyArrayObject_fields definition in
> > ndarraytypes.h that is used to enforce access to the members through
> inline
> > functions rather
Hi,
This e-mail is an attempt at proposing an API to solve Numba's needs.
Attribute access
int PyUFunc_Nin(PyUFuncObject *)
Replaces ufunc->nin.
int PyUFunc_Nout(PyUFuncObject *)
Replaces ufunc->nout.
int PyUFunc_Nargs(PyUFuncObject *)
Replaces ufunc->nargs.
PyObjec
On Mon, 21 Sep 2015 21:38:36 -0700
Nathaniel Smith wrote:
> Hi Antoine,
>
> On Mon, Sep 21, 2015 at 2:44 AM, Antoine Pitrou wrote:
> >
> > Hi Nathaniel,
> >
> > On Sun, 20 Sep 2015 21:13:30 -0700
> > Nathaniel Smith wrote:
> >> Given this, I propose that for 1.11 we:
> >> 1) go ahead and hide/d
>
> until then our only real options are either hard breaks or nothing, so
> unless we want to do a hard break there's not much point talking about
> it.
I think this is the most important sentence from this thread. Thank you
Nathaniel for you extremely thorough analysis of the impact on real-w
Hi Antoine,
On Mon, Sep 21, 2015 at 2:44 AM, Antoine Pitrou wrote:
>
> Hi Nathaniel,
>
> On Sun, 20 Sep 2015 21:13:30 -0700
> Nathaniel Smith wrote:
>> Given this, I propose that for 1.11 we:
>> 1) go ahead and hide/disable the problematic parts of the ABI/API,
>> 2) coordinate with the known af
On Mon, Sep 21, 2015 at 7:29 AM, Jaime Fernández del Río
wrote:
> We have the PyArrayObject vs PyArrayObject_fields definition in
> ndarraytypes.h that is used to enforce access to the members through inline
> functions rather than directly, which seems to me like the right way to go:
> don't lea
We have the PyArrayObject vs PyArrayObject_fields definition in
ndarraytypes.h that is used to enforce access to the members through inline
functions rather than directly, which seems to me like the right way to
go: don't leave stones unturned, hide everything and provide PyUFunc_NIN,
PyUFunc_NOUT
Hi Nathaniel,
On Sun, 20 Sep 2015 21:13:30 -0700
Nathaniel Smith wrote:
> Given this, I propose that for 1.11 we:
> 1) go ahead and hide/disable the problematic parts of the ABI/API,
> 2) coordinate with the known affected projects to minimize disruption
> to their users (which is made easier si
Hi all,
Here's a first draft NEP for comments.
--
Synopsis
Improving numpy's dtype system requires that ufunc loops start having
access to details of the specific dtype instance they are acting on:
e.g. an implementation of np.equal for strings needs access to the
dtype object in order
15 matches
Mail list logo