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-scipy-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.

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