DEP: Deprecate private namespaces in scipy.linalg

[Smit-create]

• Reference issue: Making clearer what namespaces are public by use of underscores #14360

cc @rgommers

[ilayn]

Is it possible to use git mv old_name new_name then add the old_name.pys so that the diffs are much smaller? Rght now they are a bit on top of each other. And git can follow renames quite well.

[Smit-create]

Is it possible to use git mv old_name new_name then add the old_name.pys so that the diffs are much smaller?

Yes, I have used git mv to rename see: aa53069

[ilayn]

That's strange. GitHub should have caught this and show nonunderscored files as new files rather than diffing them.

[rgommers]

That's strange. GitHub should have caught this and show nonunderscored files as new files rather than diffing them.

This is a known problem with the GitHub UI - reviewing individual commits will work around this. Each of these PRs should have 2 commits, the first with a bunch of git mv renames and nothing else, the second one with the code changes.

[ilayn]

Ah OK then nevermind. I am still not looking forward to this change and it's possible breakage downstream but let's do it once and for all 😄

[rgommers]

The Lint job doesn't always have to pass, but it would be good to clean it up as much as possible. You can run the checks locally with python tools/lint_diff.py. These are easy to clean up:

scipy/linalg/matfuncs.py:8:12: E261 at least two spaces before inline comment

Also, could you rebase rather than merge master into your branch @Smit-create? We can't squash-merge these PRs, so clean commit history with 2 commits only is more important than for other types of PRs.

[rgommers]

So for public namespaces we have left (as documented in http://scipy.github.io/devdocs/reference/index.html):

• scipy.linalg.blas
• scipy.linalg.cython_blas
• scipy.linalg.lapack
• scipy.linalg.cython_lapack
• scipy.linalg.interpolative

If I looked at the list of .py files correctly, the one other file for which access is not deprecated is flinalg.py. I think it's meant to be private; the one function in it is get_flinalg_funcs and that's not present in the API docs.

[ilayn]

I think we have to merge this as quickly as possible to avoid constantly hit by linalg changes that are coming in. Once you are happy with the linter let's review and push it in. Then we can deal with the fallout in other PRs

[rgommers]

We should be able to get it in today I think.

[Smit-create]

which access is not deprecated is flinalg.py.

Oh, I left it because:

scipy/scipy/linalg/flinalg.py

Lines 10 to 12 in a542b67

	try:
	from . import _flinalg
	except ImportError:

is generated from:

scipy/scipy/linalg/setup.py

Lines 90 to 93 in a542b67

	config.add_extension('_flinalg',
	sources=[join('src', 'det.f'), join('src', 'lu.f')],
	extra_info=lapack_opt
	)

So, should I change it as flinalg.py -> _flinalg.py and _flinalg(in setup) -> __flinalg ?

[rgommers]

So, should I change it as flinalg.py -> _flinalg.py and _flinalg(in setup) -> __flinalg ?

Probably easier to leave the compiled extension as it is now, and just rename finalg.py to _flinalg_py.py. There's only a couple of usages, so that should be straightforward.

[ilayn]

This bot is relentless :)

[Smit-create]

The Lint job doesn't always have to pass, but it would be good to clean it up as much as possible.

Initially it showed a few failures but now there are a bunch of errors, I'll resolve them in some other PR

[rgommers]

Initially it showed a few failures but now there are a bunch of errors, I'll resolve them in some other PR

That's not necessary - the check only runs on the diff in the PR, so let's just fix the obvious problems and ignore the rest (once we merge this PR, master will not have a problem). For example "line too long" can be safely ignored, often it makes code harder to read rather than easier if it's just over 79 characters long.

[rgommers]

LGTM now, thanks @Smit-create!