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@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@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion