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

[Ralf Gommers]

On Sat, Apr 6, 2013 at 7:22 PM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> On Sat, Apr 6, 2013 at 1:51 AM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
> >
> >
> >
> > On Sat, Apr 6, 2013 at 4:47 AM, Matthew Brett <matthew.brett at gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Apr 5, 2013 at 7:39 PM,  <josef.pktd at gmail.com> 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
> > 'order'.
> >
> > 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.
>

You have had clear NOs to the various incarnations of your proposal from 3
active developers of this community, not once but two or three times from
each of those developers. Furthermore you have got only a couple of +0.5s,
after 90 emails no one else seems to feel that this is a change we really
have to have this change. Therefore I don't expect another modification of
your proposal, I expect you to drop it.

As another poster said, this thread has run its course. The technical
issues are clear, and apparently we're going to have to agree to disagree
about the seriousness of the confusion. Please please go and fix the docs
in the way you deem best, and leave it at that. And triple please not
another governance thread.

I'm am honestly sorry that I offended you.


Thank you. I apologize as well if my tone of the last message was too
strong.

Ralf

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
> > OK.
>
> 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
> better solution.
>
> Cheers,
>
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130406/47b6e345/attachment.html>