Skip to content

[MRG] Deprecate any import that is not from sklearn.neural_network #14913

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

NicolasHug
Copy link
Member

@NicolasHug NicolasHug commented Sep 6, 2019

Addresses part of #12927 and part of #9250

This PR renames file.py into _file.py in the sklearn.neural_network module.

Imports from sklearn.neural_network.file are still possible, but deprecated. The message explicitly says to only import tools from sklearn.neural_network.

The diff looks much more impressive that it actually is, due to file renaming.

From #12927 I understand that @adrinjalali @glemaitre @GaelVaroquaux @amueller are happy with this change. Ping also @thomasjpfan

ping @rth in particular because I think you had concerns about doing this.

The main result is that anything not in sklearn/neural_network/__init__.py will now be private!!

(lint issue should be ignored.)

@NicolasHug NicolasHug changed the title [MOMRG] Renamed files with leading underscore in neural_network module [MRG] Deprecate any import that is not from sklearn.neural_network Sep 6, 2019
Copy link
Member

@thomasjpfan thomasjpfan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we put this in the Recently deprecated section?

Copy link
Member

@adrinjalali adrinjalali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I was just wondering if doing git mv for the existing files and then creating the new ones would help with the git log.

# We don't want pytest to run these files since they immediately raise a
# DeprecationWarning
collect_ignore_glob = [
"sklearn/neural_network/rbm.py", # 0.24
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this also result in the doctests not to run?

Copy link
Member

@rth rth Sep 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, maybe rather not raise the warning in a pytest session?

Something like ,

import sys
if not getattr(sys, '_is_pytest_session', False):
    warnings.warn(...)

in the affected files, where sys._is_pytest_session is already set in conftest.py

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no docstring in rbm.py. There's almost no code in these files now, all they do is raises a warning.

@rth I have no strong opinion but I think that we should rather have pytest ignore a file, rather than have a file have specific behavior for pytest. LMK.

Copy link
Member

@rth rth Sep 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no docstring in rbm.py. There's almost no code in these files now, all they do is raises a warning.

For now. Hard to to know some time later that this file is ignored by pytest just by looking at it (or to remove that line once the file is removed). I think if we can do deprecations locally without touching global config files it is better.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now

I don't see the file evolving, ever? This is the file we just created.

We only need to ignore the file because we run the tests with -Werror::DeprecationWarning. Not raising the warning when we are in a pytest session is treating the issue in the reverse order IMO, but OK. I'll address it in #14939 if you don't mind

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the file evolving, ever? This is the file we just created.

Me neither, but who knows. Accidents and messed up merge conflicts do happen.

Not raising the warning when we are in a pytest session is treating the issue in the reverse order IMO, but OK.

Yes, I agree it's not ideal, but both this and changing the conftest.py is a way around our non standard use of error on warning. Not sure if there is a better solution.

Copy link
Member

@rth rth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments, otherwise LGTM.

@NicolasHug
Copy link
Member Author

Thanks for the feedback!

I was just wondering if doing git mv for the existing files and then creating the new ones would help with the git log.

I used git mv but that doesn't help with the diff unfortunately :(

I would like to do the same for all modules, please comment on #12927 (comment) ;)

Copy link
Member

@rth rth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, do you know why the lint CI fails?

@NicolasHug
Copy link
Member Author

LGTM, do you know why the lint CI fails?

Any lint issue that used to be in file.py is now in _file.py, which is considered as a new file, so it triggers the CI as a new lint issue.

I'd rather not fix the lint issues since it would be pretty much impossible to catch the changes in the diff (and there's a minimal chance that things can go wrong?).

@glemaitre
Copy link
Member

glemaitre commented Sep 9, 2019

I'd rather not fix the lint issues since it would be pretty much impossible to catch the changes in the diff (and there's a minimal chance that things can go wrong?).

+1

Copy link
Member

@adrinjalali adrinjalali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just to be on the safe side, I'd send a [doc build] commit to see if we have any deprecated imports in our own docs. Assuming the CI fails on DeprecationWarnings.

@NicolasHug
Copy link
Member Author

I've opened #14939, maybe we can merge that one instead? It is more generic and will help deprecate the rest of the modules. But overall it does exactly the same job

@rth
Copy link
Member

rth commented Sep 10, 2019

I've opened #14939, maybe we can merge that one instead? It is more generic and will help deprecate the rest of the modules.

Sure. Closing this one then to avoid confusing reviewers :)

@rth rth closed this Sep 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants