On Fri, Dec 28, 2018, at 10:58 AM, Ralf Gommers wrote:
>
> Technically there's nothing we are deprecating. If anything, the one not
> super uncommon pattern will be that people use 0/1 instead of False/True,
> which works as expected now and will start raising in case we'd go with
> np.never_copy
Oh, no, here I meant, I'd consider `np.modes.CLIP` to be something worth
advocating for if it wasn't for deprecation cycles and extremely widespread
usage.
>> But now that we have good typing in Python, I think of string literals as an
>> anti-pattern going forward.
>
> I don't quite get that, it'll still be the most Pythonic thing to do in many
> API design scenarios. Adding a new class instance with unusual behavior like
> raising on bool() is not even a pattern, it would just be an oddity.
Oh, no, I wouldn't suggest that the class raise on boolification, I suggest
that the typing module warn if something other than a bool or an
np.types.CopyMode is provided. Then you can have a useful typed function
signature.
>> I have a lot of sympathy for the ugliness argument, but I don't think
>> `np.never_copy` (or e.g. `np.modes.never`) is that much worse than a string.
>
> The point is not that `.reshape(..., copy=np.never_copy)` is uglier (it is,
> but indeed just a little), but that we're adding a new object to the numpy
> namespace that's without precedent. If we'd do that regularly the API would
> really blow up.
Sure, I totally agree here, which is why I suggested `np.modes.never` as an
alternative. Namespaces are a honking great idea!
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
