[Numpy-discussion] copy="never" discussion and no deprecation cycle?
a.h.jaffe at gmail.com
Fri Jun 25 05:30:00 EDT 2021
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".
More information about the NumPy-Discussion