On Sun, Apr 28, 2019 at 8:42 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> In summary, I think the guarantees should be as follows:
> 1.If you call np.function and
> - do not define __array_function__, changes happen only via the usual
> cycle.
> - define __array_function__, you
Hi Nathaniel,
Thanks, I now see your point. I think I can weasel my way partially out:
the default *output* from `np.concatenate` is an ndarray, so in that
respect it is not that strange that when no input defines
__array_function__, one would call `ndarray.__array_function__` (I realize
this is s
On Sun, Apr 28, 2019 at 1:38 PM Marten van Kerkwijk
wrote:
>
> Hi Nathaniel,
>
> I'm a bit confused why` np.concatenate([1, 2], [3, 4])` would be a problem.
> In the current model, all (numpy) functions fall back to
> `ndarray.__array_function__`, which does know what to do with anything that
>
Hey Stephan,
After some discussion with Ralf, I feel that the best way forward would be to
add the __numpy_implementation__ (which is my preferred name for it). While I
consider the interface final (or at least to the point where we would only add
functionality and not remove it), I would prefe
Hi Nathaniel,
I'm a bit confused why` np.concatenate([1, 2], [3, 4])` would be a problem.
In the current model, all (numpy) functions fall back to
`ndarray.__array_function__`, which does know what to do with anything that
doesn't have `__array_function__`: it just coerces it to array. Am I
missin
On Sun, Apr 28, 2019, 02:22 Ralf Gommers wrote:
> One other thought: the proposal in this thread is about skipping the
> override mechanism for numpy functions. NEP 18 reserves the freedom to swap
> out __array_function__ with __array_ufunc__ if we make something a ufunc.
> So __skipping_array_fu
On Sun, Apr 28, 2019, 08:41 Marten van Kerkwijk
wrote:
> Hi Ralf,
>
> Thanks for the comments and summary slides. I think you're
> over-interpreting my wish to break people's code! I certainly believe - and
> think we all agree - that we remain as committed as ever to ensure that
> ```
> np.funct
On Sun, Apr 28, 2019 at 7:43 PM Evgeni Burovski
wrote:
> Hi Ralf,
>
> Would it be much hassle for you to duplicate your slides somewhere else,
> too?
>
Oh fun, SlideShare is blocked in Russia I see. So is
https://speakerdeck.com/. I just sent you the slides, will think about a
more structural so
Hi Ralf,
Would it be much hassle for you to duplicate your slides somewhere else,
too?
Cheers,
Evgeni
вс, 28 апр. 2019 г., 15:38 Ralf Gommers :
>
>
> On Sat, Apr 27, 2019 at 8:10 PM Ralf Gommers
> wrote:
>
>>
>> It seems like we all have a different mental model of what NEP 18
>> actually doe
On Sun, Apr 28, 2019 at 6:57 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Agreed that the coercion right now is *not* generic, with some doing
> `asarray`, others `asanyarray` and yet others nothing. There are multiple
> possible solutions, with one indeed being that f
Hi Ralf,
Agreed that the coercion right now is *not* generic, with some doing
`asarray`, others `asanyarray` and yet others nothing. There are multiple
possible solutions, with one indeed being that for each function one moves
the coercion bits out to an associated intermediate function. In princi
On Sun, Apr 28, 2019 at 5:41 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Thanks for the comments and summary slides. I think you're
> over-interpreting my wish to break people's code! I certainly believe - and
> think we all agree - that we remain as committed as ever
Hi Ralf,
Thanks for the comments and summary slides. I think you're
over-interpreting my wish to break people's code! I certainly believe - and
think we all agree - that we remain as committed as ever to ensure that
```
np.function(inputs)
```
continues to work just as before. My main comment is t
On Sat, Apr 27, 2019 at 8:10 PM Ralf Gommers wrote:
>
> It seems like we all have a different mental model of what NEP 18 actually
> does. I'm going to try to put mine on a few slides with diagrams/examples
> to see if that helps, since mailing list threads are hard to process.
>
Here is my atte
On Sun, Apr 28, 2019 at 5:02 AM Nathaniel Smith wrote:
> On Sat, Apr 27, 2019 at 7:46 PM Stephan Hoyer wrote:
> > Worst, "__wrapped__" would be difficult to search for, because it
> already means something in Python (referring to functools.wrapped). At
> least "__numpy_implementation__" and "__s
15 matches
Mail list logo
