Deprecate inexact matches for mode, order etc ?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Deprecate inexact matches for mode, order etc ?

Anirudh Subramanian
Hi all,

I added a proposal to deprecate inexact and case insensitive matches for mode, order, searchside and sortkind. in https://github.com/numpy/numpy/pull/16056 , and this stemmed from a discussion started in https://github.com/numpy/numpy/pull/16007#discussion_r410517462 

Currently, numpy allows :
np.ravel_multi_index(arr, (7, 6), mode='Clip')
np.ravel_multi_index(arr, (7, 6), mode='C')
np.ravel_multi_index(arr, (7, 6), mode='cat')

We have a similar story for order, searchside and sortkind. After the change, all non exact and case insensitive matches will give a deprecationwarning i.e. only exact matches for mode('clip', 'wrap' and 'raise'), order('C', 'F', 'A', 'K'), searchside ('left', 'right') and sortkind ('merge', 'heap', 'stable', 'quick') will be valid.

The PR also includes 'byteorder' but i am not too sure about this since  (as pointed out in the PR) sys.byteorder uses 'big', 'little' etc. while the numpy documentation uses single capital character to indicate byteorder ('S', 'L’, 'B', 'N', 'I'). 

Anirudh

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate inexact matches for mode, order etc ?

Sebastian Berg
On Fri, 2020-05-01 at 13:58 -0700, Anirudh Subramanian wrote:

> Hi all,
>
> I added a proposal to deprecate inexact and case insensitive matches
> for
> mode, order, searchside and sortkind. in
> https://github.com/numpy/numpy/pull/16056 , and this stemmed from a
> discussion started in
> https://github.com/numpy/numpy/pull/16007#discussion_r410517462
>
> Currently, numpy allows :
> np.ravel_multi_index(arr, (7, 6), mode='Clip')
> np.ravel_multi_index(arr, (7, 6), mode='C')
> np.ravel_multi_index(arr, (7, 6), mode='cat')
>
> We have a similar story for order, searchside and sortkind. After the
> change, all non exact and case insensitive matches will give a
> deprecationwarning i.e. only exact matches for mode('clip', 'wrap'
> and
> 'raise'), order('C', 'F', 'A', 'K'), searchside ('left', 'right') and
> sortkind ('merge', 'heap', 'stable', 'quick') will be valid.
>
> The PR also includes 'byteorder' but i am not too sure about this
> since
> (as pointed out in the PR) sys.byteorder uses 'big', 'little' etc.
> while
> the numpy documentation uses single capital character to indicate
> byteorder
> ('S', 'L’, 'B', 'N', 'I').


Thanks for working on this.

For the byteorder, maybe we should just allow both for now? SciPy uses
"S" once, that is the default though. `=`, `>`, `<` (or "native", etc.)
are much nicer than `N`, `B`, `L` anyway, because that is what we
print. (I am not sure that `I`, which is also spelled `|`, has a useful
meaning as an argument to be honest.)

I think I would prefer allowing all of `>`, `B`, and `big`. But change
the documentation to not mention the single letter `B`. And some future
people/us can think about deprecating them in a few years...

In any case, I am absolutely +1 but would be very happy to e.g. keep
allowing single letter abbreviations if anyone thinks that they are
occasionally used out there.

Cheers,

Sebastian


>
> Anirudh
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion