Yes, I have engaged with Konrad before on this issue on twitter and GitHub. However, I have to say I disagree with most of his take on backwards compatibility issues. I don't want to revamp that discussion once again but I don't buy this "old code" argument. Old code also has to be maintained continuously. I don't mean to break things in every release but then again any "ENH" PR can be rejected with the same argument such that we can only fix bugs and nothing else.

Personally, this was the reason that pushed me away from matlab with strange syntax and unusable UX choices that has been around since 30 years (8.3 filenames, nargin, nargout frenzy etc.). But even mathworks break code pretty often in every toolbox, see some of the exclamation marks, say in, https://ww2.mathworks.cn/help/control/release-notes.html

These keywords won't be removed, possibly, until v.1.5.x only warning will be emitted hence there is ample time to adapt. To be clear on the Python3 detail, it was about the keyword order restrictions.





On Mon, Apr 23, 2018 at 3:23 PM, Pauli Virtanen <pav@iki.fi> wrote:
ma, 2018-04-23 kello 12:20 +0200, Ilhan Polat kirjoitti:
[clip: solve(sym_pos=, debug=)]
> Hence I've proposed to deprecate these in
> https://github.com/scipy/scipy/pull/8715/files . Pauli also chimed in
> and
> mentioned that this might not be a good idea since this is a central
> function and the benefits might not be worth the effort and backwards
> compatibility problems. With Python2 dying, I think the backwards
> compatibility part won't be such important problem anymore and the
> benefit
> is that we don't need to have such strange signature.

This I think is relevant:

http://blog.khinsen.net/posts/2017/11/22/stability-in-the-scipy-ecosystem-a-summary-of-the-discussion/

My own position is that any breakage should have good reasons behind
it, and cosmetic reasons (function signature with some duplicated
functionality) usually are not strong enough.

Re: Python3 --- I think that Python 3 also breaks things should not be
a permission to break more things.

        Pauli
_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev