On Thu, Oct 25, 2018 at 3:10 PM Andras Deak <deak.andris@gmail.com> wrote:

On Thu, Oct 25, 2018 at 11:48 PM Joseph Fox-Rabinovitz
<jfoxrabinovitz@gmail.com> wrote:
>
> In that vein, would it be advisable to re-implement them as aliases for the correctly behaving functions instead?
>
> - Joe

Wouldn't "probably, can't be changed without breaking external code"
still apply? As I understand the suggestion for _deprecation_ is only
because there's (a lot of) code relying on the current behaviour (or
at least there's risk).

I would also advocate for fixing these functions if possible (removing ndim=1). ascontiguousarray(...) is certainly more readable than asarray(... order='C').

The conservative way to handle this would be to do a deprecation cycle, specifically by issuing FutureWarning when scalars or 0d arrays are encountered as inputs.

Cheers,

Stephan