<div dir="ltr"><div>In that vein, would it be advisable to re-implement them as aliases for the correctly behaving functions instead?</div><div><br></div><div>- Joe<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 5:01 PM Joe Kington <<a href="mailto:joferkington@gmail.com">joferkington@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>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.  <br></div><div><br></div><div>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.<br></div><div><br></div><div>Just my $0.02, anyway.  Cheers,</div><div>-Joe<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 3:17 PM Alex Rogozhnikov <<a href="mailto:alex.rogozhnikov@yandex.ru" target="_blank">alex.rogozhnikov@yandex.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Dear numpy community,</div><div> </div><div>I'm planning to depreciate np.asfortranarray and np.ascontiguousarray</div><div>functions due to their misbehavior on scalar (0-D tensors) with PR <span>#12244</span>.</div><div> </div><div>Current behavior (converting scalars to 1-d array with single element)</div><div>- is unexpected and contradicts to documentation</div><div>- probably, can't be changed without breaking external code</div><div>- I believe, this was a cause for poor support of 0-d arrays in mxnet.</div><div>- both functions are easily replaced with asarray(..., order='...'), which has expected behavior</div><div> </div><div>There is no timeline for removal - we just need to discourage from using this functions in new code.</div><div> </div><div>Function naming may be related to how numpy treats 0-d tensors specially,  </div><div>and those probably should not be called arrays.</div><div><div><a href="https://www.numpy.org/neps/nep-0027-zero-rank-arrarys.html" target="_blank">https://www.numpy.org/neps/nep-0027-zero-rank-arrarys.html</a></div><div>However, as a user I never thought about 0-d arrays being special and being "not arrays".</div><div> </div></div><div> </div><div>Please see original discussion at github for more details</div><div><a href="https://github.com/numpy/numpy/issues/5300" target="_blank">https://github.com/numpy/numpy/issues/5300</a></div><div> </div><div>Your comments welcome,</div><div>Alex Rogozhnikov<br> </div>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>