[Numpy-discussion] Depreciating asfortranarray and ascontiguousarray

Sebastian Berg sebastian at sipsolutions.net
Tue Oct 30 10:54:07 EDT 2018


On Sat, 2018-10-27 at 19:29 +1300, Ralf Gommers wrote:
> 
> 
> On Sat, Oct 27, 2018 at 6:37 PM Eric Wieser <
> wieser.eric+numpy at gmail.com> wrote:
> > > in order to be used prior to calling C or Fortran code that
> > > expected at least a 1-d array
> > > 
> > 
<snip>
> 
>  
> > > I'm a big supporter of making a NumPy 2.0 and have been for
> > > several years. Now that Python 3 transition has happened, I think
> > > we could seriously discuss this.
> 
> I think it's more helpful to discuss goals and concrete plans for
> those, rather than a "NumPy 2.0" label. The latter never worked in
> the past, and not just because of lack of time/funding - it just
> means different things to different people. We now have a good start
> on what our major goals are (http://www.numpy.org/neps/#roadmap),
> let's build on that.

I agree. I do think that we should not be scared of a major release.
But, I would rather see it as a step towards, for example, better
dtypes. Aiming for a large cleanup seems like it might be a can of
worms [0].

About the asfortranarray/ascontiguousarray thing. I am not sure I like
FutureWarnings in the edge cases, it seems likely they arise randomly
on functions where the devs may not even be aware of it.
I do not like spamming the the API, but if we cannot agree on a nice
way forward, maybe this is a point where creating new names is an
options:

 * ascorderarray/asforderarray
 * asccontiguousarray/asfcontigouousarray
 * np.asarray(..., order='C'), is somewhat the same I guess

not sure I like the names too much, but I think we could find new names
here.
And then putting warnings is IMO OK, if there is a an easy/nice enough
way to avoid them (sure we can start in documentation if it helps).
We can wait for the actual removal for very long and at least until the
next major release or so, I do not think it matters much as long as
visible deprecation warnings exist to push downstream into changing
habits/code, the maintenance burden is pretty much zero after all.

Discussing how to approach larger changes is important, but I doubt
that these particular functions are problematic enough!

- Sebastian


[0] Happy to be shown wrong, but I seriously fear that aiming too high
will hinder progress -- unless maybe there is some very good funding
and skilled devs, but even then it might be too ambitious? -- and I am
not even sure it is easier on downstream.


> 
> > >   I'm trying to raise funding for maintenance and progress for
> > > NumPy and SciPy right now via Quansight Labs 
> > > http://www.quansight.com/labs and I hope to be able to help find
> > > grants to support the wonderful efforts that have been happening
> > > for some time. 
> 
> The NumPy grant and having Tyler/Matti/Stefan at BIDS is a great
> start to funded development; more and more diverse funding sources
> would be awesome.

Yes, that is very cool news!

- Sebastian

> 
> Cheers,
> Ralf
> 
> > > While I'm thrilled and impressed by the number of amazing devs
> > > who have kept NumPy and SciPy going in mostly their spare time,
> > > it has created challenges that we have not had continuous
> > > maintenance funding to allow continuous paid development so that
> > > several people who know about the early decisions could not be
> > > retained to spend time on helping the transition.  
> > > 
> > > Your bringing the problem of mxnet devs is most appreciated.  I
> > > will make a documentation PR.
> > > 
> > > -Travis
> > > 
> > > 
> > > 
> > > >  
> > > > Alex.
> > > >  
> > > >  
> > > > 27.10.2018, 02:27, "Travis Oliphant" <teoliphant at gmail.com>:
> > > > > 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
> > > > _______________________________________________
> > > > 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
> > > 
> > 
> > _______________________________________________
> > 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20181030/380af5c5/attachment.sig>


More information about the NumPy-Discussion mailing list