[Numpy-discussion] Splitting MaskedArray into a separate package

Ilhan Polat ilhanpolat at gmail.com
Wed May 23 16:57:35 EDT 2018


 As far as I understand from the discussion above, I think the opposite
would be a better strategy for the sanity of our scarce but brave
maintainers. I would argue that if there is a maintenance burden, then the
ballasts seem to be the linalg and random indeed. Similar pain points exist
in SciPy too. There are a lot of issues that has been already thought of,
years ago but never materialized (be it backwards compatibility, lack of
champions and so on) because they are not the priority of the maintaining
team. It is very common that a discussion ends with "yes, we should
probably make it a ufunc" and then fades away. I feel that if there were
less things to worry about more people would step up and "do it".

I would also argue that highest expectancy from NumPy would be having a
really sound data structure basis with more ufuncs, more array manipulation
tricks and so on. Masked arrays, imho, fall into that category. Hence, if
the codebase gets more refined in that respect and less stuff to maintain,
less moving parts, I think there would be a more coherent overall picture
and more focused action plan. Now the attention of maintainers seem to be
divided into a lot of orthogonal issues which is not a bad thing per se but
tedious at times. Currently NumPy has a lot of code that really doesn't
need to bother and can delegate to higher level packages like SciPy or any
other subpackage. It sounds like NumPy 2.0 but actually more of a gradual
thinning out.




On Wed, May 23, 2018 at 10:51 PM, Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> Hi Eric,
>
> On May 23, 2018 13:25:44 Eric Firing <efiring at hawaii.edu> wrote:
>
> On 2018/05/23 9:06 AM, Matti Picus wrote:
>> I understand at least some of the motivation and potential advantages,
>> but as it stands, I find this NEP highly alarming.
>>
>
> I am not at my computer right now, so I will respond in more detail later.
> But I wanted to address your statement above:
>
> I see a NEP as an opportunity to discuss and flesh out an idea, and I
> certainly hope that you there's no reason for alarm.
>
> I do not expect to know whether this is a good idea before discussions
> conclude, so I appreciate your feedback. If we cannot find good support for
> the idea, with very specific benefits, it should simply be dropped.
>
> But, I think there's a lot to learn from the conversation in the meantime
> w.r.t. exactly how streamlined people want NumPy to be, how core
> functionality can perhaps be strengthened by becoming a customer of our own
> API, how to optimally maintain sub-components, etc.
>
> Best regards,
> Stéfan
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180523/62502383/attachment.html>


More information about the NumPy-Discussion mailing list