[Numpy-discussion] copy="never" discussion and no deprecation cycle?

Gagandeep Singh gsingh at quansight.com
Thu Jun 24 00:12:09 EDT 2021


To me, adding enums as attributes of the `np.copy` function seems like a
pretty good idea. This trick might resolve the only relatively important
issue with Enums. Then, the benefits of Enum might outweigh the
disadvantage of uncommon of usage of Enums in NumPy APIs. As an end user, I
would like Enums rather than strings as the former would provide fixed
number of choices (hence, easy debugging) as compared to the latter (in
which case, infinite choices for passing strings and the code may work
silently, imagine, passing, `if_neded` instead of `if_needed` and it
working perfectly fine (silently). This thing has happened to me while
using another library.

On Thu, Jun 24, 2021 at 8:05 AM Benjamin Root <ben.v.root at gmail.com> wrote:

> Why not both? The definition of the enum might live in a proper namespace
> location, but I see no reason why `np.copy.IF_NEEDED =
> np.flags.CopyFlgs.IF_NEEDED` can't be done (I mean, adding the enum members
> as attributes to the `np.copy()` function). Seems perfectly reasonable to
> me, and reads pretty nicely, too. It isn't like we are dropping support for
> the booleans, so those are still around for easy typing.
>
> Ben Root
>
> On Wed, Jun 23, 2021 at 10:26 PM Stefan van der Walt <stefanv at berkeley.edu>
> wrote:
>
>> On Wed, Jun 23, 2021, at 18:01, Juan Nunez-Iglesias wrote:
>> > Personally I was a fan of the Enum approach. People dislike it because
>> > it is not “Pythonic”, but imho that is an accident of history because
>> > Enums only appeared (iirc) in Python 3.4. In fact, they are the right
>> > data structure for this particular problem, so for my money we should
>> > *make it* Pythonic by starting to use it everywhere where we have a
>> > finite list of choices.
>>
>> The enum definitely feels like the right abstraction. But the resulting
>> API is clunky because of naming and top-level scarcity.
>>
>> Hence the suggestion to tag it onto np.copy, but there is an argument to
>> be made for consistency by placing all enums under np.flags or similar.
>>
>> Still, np.flags.copy.IF_NEEDED gets long.
>>
>> Stéfan
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> 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: <https://mail.python.org/pipermail/numpy-discussion/attachments/20210624/bc2fe3fb/attachment.html>


More information about the NumPy-Discussion mailing list