On 25/06/2021 02:12, Stephan Hoyer wrote:
I think Enums are a very clean abstraction for capturing a discrete set of options in a type-safe way, both at runtime and with static checks. You also don't have to keep lists of strings in sync, which makes them a little easier to document.
That said, I agree that in most cases the overall benefits are rather marginal. I don't think it's worth a mass migration of existing NumPy functions, which uses strings for categorical options.
In this particular case, I think there is a clear advantage to using an enum, to avoid inadvertent bugs with old versions of NumPy.
At some point in the future, we might either: (1) switch the interface to use strings, in which case we would stop recommending/documenting CopyMode (like plenty of other top level objects in the NumPy namespace) (2) add many more enums, in which case we can consider assigning enums as function attributes or putting them in a namespace. But so far the only other enum I've heard suggested is np.ClipMode. Adding two enums to the NumPy namespace would hardly make a difference at this point, given how many objects are already there.
I'm just an interested observer, but it seems that going the enum route is a clear "practicality beats purity" decision for this case. I really don't see the need to eventually move [back] to strings.
Also, perhaps I missed a discussion of it in the thread, but aren't enums also better for typechecking?
I actually prefer enums overall for a number of reasons, but I agree that they are not worth a "mass migration".