[Numpy-discussion] Raveling, reshape order keyword unnecessarily confuses index and memory ordering
Sat Apr 6 12:22:09 CDT 2013
On Sat, Apr 6, 2013 at 1:51 AM, Ralf Gommers <firstname.lastname@example.org> wrote:
> On Sat, Apr 6, 2013 at 4:47 AM, Matthew Brett <email@example.com>
>> On Fri, Apr 5, 2013 at 7:39 PM, <firstname.lastname@example.org> wrote:
>> > It's not *any* cost, this goes deep and wide, it's one of the basic
>> > concepts of numpy that you want to rename.
>> The proposal I last made was to change the default name to 'layout'
>> after some period to be agreed - say - P - with suitable warning in
>> the docstring up until that time, and after, and leave 'order' as an
>> alias forever.
> The above paragraph is simply incorrect. Your last proposal also included
> deprecation warnings and a future backwards compatibility break by removing
> If you now say you're not proposing steps 3 and 4 anymore, then you're back
> to what I called option (2) - duplicate keywords forever. Which for me is
> undesirable, for reasons I already mentioned.
You might not have read my follow-up proposing to drop steps 3 and 4
if you felt they were unacceptable.
> P.S. being called short-sighted and damaging numpy by responding to a
> proposal you now say you didn't make is pretty damn annoying.
No, I did make that proposal, and in the spirit of negotiation and
consensus, I subsequently modified my proposal, as I hope you'd expect
in this situation.
I'm am honestly sorry that I offended you. In hindsight, although I do
worry that numpy feels as if it does resist reasonable change more
strongly than is healthy, I was probably responding to my feeling that
you were trying to veto the discussion rather than joining it, and I
really should have put it that way instead. I am sorry about that.
> P.P.S. expect an identical response from me to future proposals that include
> backwards compatibility breaks of heavily used functions for something
> that's not a functional enhancement or bug fix. Such proposals are just not
It seems to me that each change has to be considered on its merit, and
strict rules of that sort are not very useful. You are again implying
that this change is not important, and obviously there I don't agree.
I addressed the level and timing of backwards compatibility breakage
in my comments to Josef. You haven't responded to me on that.
> P.P.P.S. I'm not sure exactly what you mean by "default keyword". If layout
> overrules order and layout's default value is not None, you're still
> proposing a backwards compatibility break.
I mean, that until the expiry of some agreed period 'P' - the
docstring would read
def ravel(self, order='C', **kwargs)
where kwargs can only contain 'layout', and 'layout', 'order' cannot
both be defined
and after the expiry of 'P'
def ravel(self, layout='C', **kwargs)
where kwargs can only contain 'order', and 'layout', 'order' cannot
both be defined
At least that's my proposal, I'm happy to change it if there is a
More information about the NumPy-Discussion