linalg.solve keyword deprecation
Hi there, Some time ago, we have included different matrix structure types such as symmetric, positive definite and hermitian together with the generic matrices to solve AX=B problems in linalg.solve. Previously, there were two keywords in the signature namely "debug" and "sym_pos". These keywords, in my opinion, are obsolete and actually clutter the function signature because the dummy keyword "debug" has no functionality and "sym_pos" is covered by "assume_a" keyword as a special case. 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. Thus, I'd like to ask around what others think about this since this indeed "needs-decision". ilhan
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-... 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
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
On Mon, Apr 23, 2018 at 9:23 AM, 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.
I think even "cosmetic" (confusing signatures) should be cleaned up in the long run, otherwise they never go away unless there is a big break release. But deprecation periods should be long, e.g. > 3 years. (I had to deprecate three functions in statsmodels because I had misspelled the function names when writing them.) Josef
Pauli _______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
On Mon, Apr 23, 2018 at 6:51 AM, <josef.pktd@gmail.com> wrote:
On Mon, Apr 23, 2018 at 9:23 AM, 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-sc ipy-ecosystem-a-summary-of-the-discussion/
I think that that story suffers from a very narrow viewpoint and a lot of exaggeration, but it's still a good example of why we need solid reasons to deprecate code.
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.
+1
I think even "cosmetic" (confusing signatures) should be cleaned up in the long run,
This is useful in principle, but the gain has to balance the cost. In a case like this, a doc-only deprecation would be fine. It could then be cleaned up at some point if there's a SciPy 2.0 in some years (with deprecation in code now). otherwise they never go away unless there is a big break release.
But deprecation periods should be long, e.g. > 3 years.
Deprecations in code (so users see a deprecation warning) have a very specific meaning: the deprecated feature gets removed after 2 releases. Ralf
(I had to deprecate three functions in statsmodels because I had misspelled the function names when writing them.)
Josef
participants (4)
-
Ilhan Polat -
josef.pktd＠gmail.com -
Pauli Virtanen -
Ralf Gommers