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

Matthew Brett matthew.brett@gmail....
Fri Apr 5 20:50:03 CDT 2013


Hi,

On Fri, Apr 5, 2013 at 4:27 PM,  <josef.pktd@gmail.com> wrote:
> On Fri, Apr 5, 2013 at 6:09 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
>> Hi,
>>
>> On Fri, Apr 5, 2013 at 12:53 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
>>>
>>>
>>>
>>> On Fri, Apr 5, 2013 at 9:21 PM, Matthew Brett <matthew.brett@gmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Fri, Apr 5, 2013 at 3:09 PM, Ralf Gommers <ralf.gommers@gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Fri, Apr 5, 2013 at 5:13 PM, Matthew Brett <matthew.brett@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> On Fri, Apr 5, 2013 at 2:20 AM, Sebastian Berg
>>>> >> <sebastian@sipsolutions.net> wrote:
>>>> >> > Hey
<snip>
>>>> >> I completely agree that we'd have to be gentle with the change.  The
>>>> >> problem we'd want to avoid is people innocently using 'layout' and
>>>> >> finding to their annoyance that the code doesn't work with other
>>>> >> people's numpy.
>>>> >>
>>>> >> 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).
>>>>
>>>> You are saying that deprecation of 'order' at any stage in the next 10
>>>> years of numpy's lifetime is a no go?
>>>
>>>
>>> For something like this? Yes.
>>
>> You are saying I think that I am wrong in thinking this is an
>> important change that will make numpy easier to explain and use in the
>> long term.
>>
>> You'd probably expect me to disagree, and I do.  I think I am right in
>> thinking the change is important - I've tried to make that case in
>> this thread, as well as I can.
>>
>>>> I think that is short-sighted and I think it will damage numpy.
>>>
>>>
>>> It will damage numpy to be conservative and not change a name for a little
>>> bit of clarity for some people that avoids reading the docs maybe a little
>>> more carefully? There's a lot of things that can damage numpy, but this
>>> isn't even close in my book. Too few developers, continuous backwards
>>> compatibility issues, faster alternative libraries surpassing numpy - that's
>>> the kind of thing that causes damage.
>>
>> We're talked about consensus on this list.  Of course it can be very
>> hard to achieve.
>
> So far the consensus is that the documentation needs improvement.

The only thing all of the No camp agree with is documentation
improvement, I think that's fair.

> After that ???

Well I think we have:

Flat-no - the change not important, almost any cost is too high

You
Ralf
Bradley

Mid-no - maybe something could work, but not sure we've seen it yet.

Chris

Middle - current situation can be confusing, maybe one of the proposed
solutions would be acceptable

Sebastian
Nathaniel

Mid-yes - previous apparent vote for argument name change

Éric Depagne
Andrew Jaffe   (sorry if I misrepresent you)

And then me.

I am trying to be balanced.  Unlike others, I think better names would
have a significant impact on how coherent numpy is to explain and use.
 It seems to me that a change would be beneficial in the long term,
and I'm confident we can agree on a schedule for that change that
would be acceptable.  But you know that.

So - as I understand our 'model' - our job is to try and come to some
shared agreement, if we possibly can.

It has been good and encouraging for me at least to see that we have
developed our ideas over the course of this thread.

Cheers,

Matthew


More information about the NumPy-Discussion mailing list