Hi, On Sat, Apr 6, 2013 at 1:51 AM, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > > On Sat, Apr 6, 2013 at 4:47 AM, Matthew Brett <matthew.br...@gmail.com> > wrote: >> >> Hi, >> >> On Fri, Apr 5, 2013 at 7:39 PM, <josef.p...@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. 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 > 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@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
