[Numpy-discussion] Depreciating asfortranarray and ascontiguousarray

Sylvain Corlay sylvain.corlay at gmail.com
Sat Oct 27 11:16:56 EDT 2018


I would also argue against deprecating these functions that we are using
increasingly in several projects that I am involved in.

On Sat, Oct 27, 2018, 01:28 Travis Oliphant <teoliphant at gmail.com> wrote:

> What is the justification for deprecation exactly?  These functions have
> been well documented and have had the intended behavior of producing arrays
> with dimension at least 1 for some time.  Why is it unexpected to produce
> arrays of at least 1 dimension?  For some users this is exactly what is
> wanted.  I don't understand the statement that behavior with 0-d arrays is
> unexpected.
>
> If the desire is to shrink the API of NumPy, I could see that.   But, it
> seems odd to me to remove a much-used function with an established behavior
> except as part of a wider API-shrinkage effort.
>
> 0-d arrays in NumPy are a separate conversation.  At this point, I think
> it was a mistake not to embrace 0-d arrays in NumPy from day one.  In some
> sense 0-d arrays *are* scalars at least conceptually and for JIT-producing
> systems that exist now and will be growing in the future, they can be
> equivalent to scalars.
>
> The array scalars should become how you define what is *in* a NumPy array
> making them true Python types, rather than Python 1-style "instances" of a
> single "Dtype" object.  You would then have 0-d arrays and these Python
> "memory" types describing what is *in* the array.
>
> There is a clear way to do this, some of which has been outlined by
> Nathaniel, and the rest I have an outline for how to implement.  I can
> advise someone on how to do this.
>
> -Travis
>
>
>
>
> On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <
> alex.rogozhnikov at yandex.ru> 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
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20181027/a156b279/attachment-0001.html>


More information about the NumPy-Discussion mailing list