[Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering

Bradley M. Froehle brad.froehle@gmail....
Fri Apr 5 17:09:58 CDT 2013


On Friday, April 5, 2013 at 12:09 PM, Ralf Gommers wrote:

> On Fri, Apr 5, 2013 at 5:13 PM, Matthew Brett <matthew.brett@gmail.com (mailto:matthew.brett@gmail.com)> wrote:
> > How about:
> >  
> > Step 1: 'order' remains as named keyword, layout added as alias,
> > comment on the lines of "layout will become the default keyword for
> > this option in later versions of numpy; please consider updating any
> > code that does not need to remain backwards compatible'.
> >  
> > Step 2: default keyword becomes 'layout' with 'order' as alias,
> > comment like "order is an alias for 'layout' to maintain backwards
> > compatibility with numpy <= 1.7.1', please update any code that does
> > not need to maintain backwards compatibility with these numpy
> > versions'
> >  
> > Step 3: Add deprecation warning for 'order', "order will be removed as
> > an alias in future versions of numpy"
> >  
> > Step 4: (distant future) Remove alias
> >  
> > ?
> A very strong -1 from me. Now we're talking about deprecation warnings and a backwards compatibility break after all. I thought we agreed that this was a very bad idea, so why are you proposing it now?
> Here's how I see it: deprecation of "order" is a no go. Therefore we have two choices here:
> 1. Simply document the current "order" keyword better and leave it at that.
> 2. Add a "layout" (or "index_order") keyword, and live with both "order" and "layout" keywords forever.
> (2) is at least as confusing as (1), more work and poor design. Therefore I propose to go with (1).  
I agree with Ralf.  It's not worth breaking backwards compatibility or supporting two flags (with only further potential for confusion).  If we were designing a system from scratch, I concede that it _might_ have been better to use 'layout' instead of 'order'…. but that decision has already been made.

This proposal fails the cost/benefit analysis, being too expensive for too little benefit.


More information about the NumPy-Discussion mailing list