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

[Andrew Jaffe]

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".