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