<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 6, 2013 at 7:22 PM, Matthew Brett <span dir="ltr"><<a href="mailto:matthew.brett@gmail.com" target="_blank">matthew.brett@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On Sat, Apr 6, 2013 at 1:51 AM, Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Sat, Apr 6, 2013 at 4:47 AM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Fri, Apr 5, 2013 at 7:39 PM, <<a href="mailto:josef.pktd@gmail.com">josef.pktd@gmail.com</a>> wrote:<br>
>> ><br>
>> > It's not *any* cost, this goes deep and wide, it's one of the basic<br>
>> > concepts of numpy that you want to rename.<br>
>><br>
>> The proposal I last made was to change the default name to 'layout'<br>
>> after some period to be agreed - say - P - with suitable warning in<br>
>> the docstring up until that time, and after, and leave 'order' as an<br>
>> alias forever.<br>
><br>
><br>
> The above paragraph is simply incorrect. Your last proposal also included<br>
> deprecation warnings and a future backwards compatibility break by removing<br>
> 'order'.<br>
><br>
> If you now say you're not proposing steps 3 and 4 anymore, then you're back<br>
> to what I called option (2) - duplicate keywords forever. Which for me is<br>
> undesirable, for reasons I already mentioned.<br>
<br>
</div>You might not have read my follow-up proposing to drop steps 3 and 4<br>
if you felt they were unacceptable.<br>
<div class="im"><br>
> P.S. being called short-sighted and damaging numpy by responding to a<br>
> proposal you now say you didn't make is pretty damn annoying.<br>
<br>
</div>No, I did make that proposal, and in the spirit of negotiation and<br>
consensus, I subsequently modified my proposal, as I hope you'd expect<br>
in this situation.<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm am honestly sorry that I offended you. </blockquote><div><br></div><div>Thank you. I apologize as well if my tone of the last message was too strong. <br><br></div><div>Ralf<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In hindsight, although I do<br>
worry that numpy feels as if it does resist reasonable change more<br>
strongly than is healthy, I was probably responding to my feeling that<br>
you were trying to veto the discussion rather than joining it, and I<br>
really should have put it that way instead. I am sorry about that.<br>
<div class="im"><br>
> P.P.S. expect an identical response from me to future proposals that include<br>
> backwards compatibility breaks of heavily used functions for something<br>
> that's not a functional enhancement or bug fix. Such proposals are just not<br>
> OK.<br>
<br>
</div>It seems to me that each change has to be considered on its merit, and<br>
strict rules of that sort are not very useful. You are again implying<br>
that this change is not important, and obviously there I don't agree.<br>
I addressed the level and timing of backwards compatibility breakage<br>
in my comments to Josef. You haven't responded to me on that.<br>
<div class="im"><br>
> P.P.P.S. I'm not sure exactly what you mean by "default keyword". If layout<br>
> overrules order and layout's default value is not None, you're still<br>
> proposing a backwards compatibility break.<br>
<br>
</div>I mean, that until the expiry of some agreed period 'P' - the<br>
docstring would read<br>
<br>
def ravel(self, order='C', **kwargs)<br>
<br>
where kwargs can only contain 'layout', and 'layout', 'order' cannot<br>
both be defined<br>
<br>
and after the expiry of 'P'<br>
<br>
def ravel(self, layout='C', **kwargs)<br>
<br>
where kwargs can only contain 'order', and 'layout', 'order' cannot<br>
both be defined<br>
<br>
At least that's my proposal, I'm happy to change it if there is a<br>
better solution.<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
<br>
Matthew<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>