In that vein, would it be advisable to re-implement them as aliases for the correctly behaving functions instead?
- Joe On Thu, Oct 25, 2018 at 5:01 PM Joe Kington <[email protected]> wrote: > For what it's worth, these are fairly widely used functions. From a user > standpoint, I'd gently argue against deprecating them. Documenting the > inconsistency with scalars seems like a less invasive approach. > > In particular ascontiguousarray is a very common check to make when > working with C libraries or low-level file formats. A significant > advantage over asarray(..., order='C') is readability. It makes the > intention very clear. Similarly, asfortranarray is quite readable for > folks that aren't deeply familiar with numpy. > > Given that the use-cases they're primarily used for are likely to be read > by developers working in other languages (i.e. ascontiguousarray gets used > at a lot of "boundaries" with other systems), keeping function names that > make intention very clear is important. > > Just my $0.02, anyway. Cheers, > -Joe > > On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov < > [email protected]> wrote: > >> Dear numpy community, >> >> I'm planning to depreciate np.asfortranarray and np.ascontiguousarray >> functions due to their misbehavior on scalar (0-D tensors) with PR #12244 >> . >> >> Current behavior (converting scalars to 1-d array with single element) >> - is unexpected and contradicts to documentation >> - probably, can't be changed without breaking external code >> - I believe, this was a cause for poor support of 0-d arrays in mxnet. >> - both functions are easily replaced with asarray(..., order='...'), >> which has expected behavior >> >> There is no timeline for removal - we just need to discourage from using >> this functions in new code. >> >> Function naming may be related to how numpy treats 0-d tensors specially, >> >> and those probably should not be called arrays. >> https://www.numpy.org/neps/nep-0027-zero-rank-arrarys.html >> However, as a user I never thought about 0-d arrays being special and >> being "not arrays". >> >> >> Please see original discussion at github for more details >> https://github.com/numpy/numpy/issues/5300 >> >> Your comments welcome, >> Alex Rogozhnikov >> >> _______________________________________________ >> NumPy-Discussion mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] https://mail.python.org/mailman/listinfo/numpy-discussion
