[SciPy-Dev] linalg.solve keyword deprecation

[Ilhan Polat]

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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20180423/ce62a17e/attachment.html>