Dear all,
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".
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
