On Tue, Sep 17, 2019 at 6:56 AM Peter Andreas Entschev
wrote:
> I agree with your point and understand how the current text may be
> misleading, so we shall make it clearer in the NEP (as done in
> https://github.com/numpy/numpy/pull/14529) that both are valid ways:
>
> * Have a genuine implement
I see what you mean now. It was my misunderstanding, I thought you
wanted to return a call to __array__ when you call np.duckarray.
I agree with your point and understand how the current text may be
misleading, so we shall make it clearer in the NEP (as done in
https://github.com/numpy/numpy/pull/
Here's a PR with a different dicsussion of __array__:
https://github.com/numpy/numpy/pull/14529
-CHB
On Mon, Sep 16, 2019 at 3:23 PM Chris Barker wrote:
> OK -- I *finally* got it:
>
> when you pass an arbitrary object into np.asarray(), it will create an
> array object scalar with the object
OK -- I *finally* got it:
when you pass an arbitrary object into np.asarray(), it will create an
array object scalar with the object in it.
So yes, I can see that you may want to raise a TypeError instead, so that
users don't get an object array scalar when they wre expecting to get an
array-lik
On Mon, Sep 16, 2019 at 2:27 PM Stephan Hoyer wrote:
> On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev
> wrote:
>
>> What would be the use case for a duck-array to implement __array__ and
>> return a NumPy array?
>
>
> Dask arrays are a good example. They will want to implement __duck_ar
On Mon, Sep 16, 2019 at 1:46 PM Peter Andreas Entschev
wrote:
> What would be the use case for a duck-array to implement __array__ and
> return a NumPy array?
some users need a genuine, actual numpy array (for passing to Cyton code,
for example).
if __array__ is not implemented, how can they ge
On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev
wrote:
> What would be the use case for a duck-array to implement __array__ and
> return a NumPy array? Unless I'm missing something, this seems
> redundant and one should just use array/asarray functions then. This
> would also prevent error
What would be the use case for a duck-array to implement __array__ and
return a NumPy array? Unless I'm missing something, this seems
redundant and one should just use array/asarray functions then. This
would also prevent error-handling, what if the developer intentionally
wants a NumPy-like array
On Mon, Aug 12, 2019 at 4:02 AM Peter Andreas Entschev
wrote:
> Apologies for the late reply. I've opened a new PR
> https://github.com/numpy/numpy/pull/14257 with the changes requested
>
thanks!
I've written a small PR on your PR:
https://github.com/pentschev/numpy/pull/1
Essentially, other
Apologies for the late reply. I've opened a new PR
https://github.com/numpy/numpy/pull/14257 with the changes requested
on clarifying the text. After reading the detailed description, I've
decided to add a subsection "Scope" to clarify the scope where NEP-30
would be useful. I think the inclusion o
On Wed, Aug 7, 2019 at 6:18 PM Charles R Harris
wrote:
>
>
> On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer wrote:
>
>> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers
>> wrote:
>>
>>>
>>> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote:
>>>
On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers
On Wed, Aug 7, 2019 at 7:10 PM Stephan Hoyer wrote:
> On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers
> wrote:
>
>>
>> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote:
>>
>>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers
>>> wrote:
>>>
>>>
The NEP currently does not say who this is meant for
On Wed, Aug 7, 2019 at 5:11 PM Ralf Gommers wrote:
>
> On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote:
>
>> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers
>> wrote:
>>
>>
>>> The NEP currently does not say who this is meant for. Would you expect
>>> libraries like SciPy to adopt it for example
On Mon, Aug 5, 2019 at 6:18 PM Stephan Hoyer wrote:
> On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers
> wrote:
>
>
>> The NEP currently does not say who this is meant for. Would you expect
>> libraries like SciPy to adopt it for example?
>>
>> The NEP also (understandably) punts on the question of w
Sure, I wouldn't mind doing that, but it would also be better to have
clear alternative/complement to duck array (as I'm hoping to be the
case with with coerce). I will try to give a bit more thought on the
coercion ideas and start writing a NEP for that this week and the
next. Perhaps we can then
On Tue, 2019-08-06 at 10:24 +0200, Peter Andreas Entschev wrote:
> Thanks for the concerns raised, and Stephan for promptly answering
> them.
>
> > An alternative to introducing np.duckarray() would be to just
> > modify np.asarray(). Of course this has backwards compatibility
> > impact, but if y
Thanks for the concerns raised, and Stephan for promptly answering them.
> An alternative to introducing np.duckarray() would be to just modify
> np.asarray(). Of course this has backwards compatibility impact, but if
> you're going to be raising a TypeError from __array__ then that impact is
>
On Mon, Aug 5, 2019 at 2:48 PM Ralf Gommers wrote:
> Having __array__ give a TypeError is fine for libraries that want to
> prevent unintentional coercion with, e.g., `np.asarray(my_ducktype)`.
> However that leaves the obvious question of what the right way is to do
> this intentionally. Would b
Hi Peter, thanks for writing that up!
On Mon, Aug 5, 2019 at 8:07 AM Peter Andreas Entschev
wrote:
> Hi,
>
> we have a new proposal for the implementation of NumPy array duck
> typing [1] [2], following the high-level overview described in NEP-22
> [3].
>
A couple of high level comments:
Havi
Hi,
we have a new proposal for the implementation of NumPy array duck
typing [1] [2], following the high-level overview described in NEP-22
[3].
Would be great to get some comments on that.
[1]
https://github.com/numpy/numpy/blob/master/doc/neps/nep-0030-duck-array-protocol.rst
[2] https://gith
20 matches
Mail list logo
