Hi All,
With the 1.17 branch coming soon, this might be a good time to make plans
about 1.18 development. A couple of possibilities are:
- Expiring old deprecations,
- Removing Python 2.7 compatibility code,
- Design of a masked array replacement.
Those proposals are not earth
On Thu, Jun 13, 2019 at 6:21 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Thanks both for the reply and sharing the link. I recognize much (from
> both sides!).
>
>
>
>>
>> More importantly, I think we should not even consider *discussing*
>> removing`
Hi Ralf,
Thanks both for the reply and sharing the link. I recognize much (from both
sides!).
>
> More importantly, I think we should not even consider *discussing*
> removing` __array_function__` from np.isposinf (or any similar one off
> situation) before there's a new bigger picture design.
(this may be a bit thinking out loudly...)
On Thu, 2019-06-13 at 07:30 +0200, Hameer Abbasi wrote:
> Hi Sebastian,
>
> One way to avoid an ugly lookup table and special cases is to store
> the amount of sign bits, the amount of integer/mantissa bits and the
> amount of exponent bits for each
On Thu, Jun 13, 2019 at 9:43 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
>
>>> I guess the one immediate question is whether `np.sum` and the like
>>> should be overridden by `__array_function__` at all, given that what should
>>> be the future recommended override
Hi Ralf,
>> I guess the one immediate question is whether `np.sum` and the like
>> should be overridden by `__array_function__` at all, given that what should
>> be the future recommended override already works.
>>
>
> I'm not sure I understand the rationale for this. Design consistency
>
On Thu, Jun 13, 2019 at 7:07 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
>
>
> On Thu, Jun 13, 2019 at 12:46 PM Stephan Hoyer wrote:
>
>
>>
>>
>>> But how about `np.sum` itself? Right now, it is overridden by
>>> __array_function__ but classes without __array_function__ support
On Thu, Jun 13, 2019 at 12:46 PM Stephan Hoyer wrote:
>
>
>> But how about `np.sum` itself? Right now, it is overridden by
>> __array_function__ but classes without __array_function__ support can also
>> override it through the method lookup and through __array_ufunc__.
>>
>> Would/should there
On Thu, Jun 13, 2019 at 9:35 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf, others,
>
>
>>> Anyway, I guess this is still a good example to consider for how we
>>> should go about getting to a new implementation, ideally with just a
>>> single-way to override?
>>>
>>>
Hi Ralf, others,
>> Anyway, I guess this is still a good example to consider for how we
>> should go about getting to a new implementation, ideally with just a
>> single-way to override?
>>
>> Indeed, how do we actually envisage deprecating the use of
>> `__array_function__` for a given part of
On Thu, Jun 13, 2019 at 2:51 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi All,
>
> `nanfunctions` use `asanyarray` currently, which as Ralf notes scuppers
> the plan to use `asarray` - sorry to have been sloppy with stating they
> "convert to array".
>
> And, yes, I'll admit to
Hi All,
`nanfunctions` use `asanyarray` currently, which as Ralf notes scuppers the
plan to use `asarray` - sorry to have been sloppy with stating they
"convert to array".
And, yes, I'll admit to forgetting that we are introducing `where` only in
1.17 - clearly we cannot rely on other classes to
On Thu, Jun 13, 2019 at 3:16 AM Stephan Hoyer wrote:
> On Wed, Jun 12, 2019 at 5:55 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> Hi Ralf,
>>
>> You're right, the problem is with the added keyword argument (which would
>> appear also if we did not still have to support the
13 matches
Mail list logo
