Skip to content

MAINT Move stuff outside of utils.__init__ #26686

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

Closed

Conversation

jeremiedbb
Copy link
Member

@jeremiedbb jeremiedbb commented Jun 23, 2023

Fixes #11633

utils.__init__ contains a bunch of unrelated functions, some public, some private.
This PR proposes to move them into dedicated submodules (creating _indexing.py, _missing.py, _optional_dependencies.py and _misc.py).

Part of the motivation is to help developing utils without having to work around circular imports, like what's happening in #26648 (comment)

there are a few functions that I did not know where to put so I put them in a _misc.py submodule. I still think it's better than having the whole utils.__init__ act as a big _misc module.

@jeremiedbb
Copy link
Member Author

jeremiedbb commented Jun 23, 2023

Even if the diff is big, it's just moving stuff around. I did not modify a single line of actual code 😄

@github-actions
Copy link

✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

Generated for commit: 0949a9c. Link to the linter CI: here

@betatim
Copy link
Member

betatim commented Jun 26, 2023

This looks like a good thing to do and the structure/grouping is probably as good as it can be given that the starting point was this mixed bag of random stuff.

One question: should we keep exposing things that used to be in sklearn.utils in that place? Basically the question is if those functions are part of the public API and how we deal with deprecation related to moving the functions to a new namespace.

@jeremiedbb
Copy link
Member Author

jeremiedbb commented Jun 26, 2023

One question: should we keep exposing things that used to be in sklearn.utils in that place?

  • For public functions (i.e. listed in classes.rst), I still left them exposed in utils
  • For almost all private functions, I stopped exposing them in utils and modified the imports in the rest of the code base to import them from their submodule.
  • Except for the functions in utils._misc that I left exposed in utils because it felt wrong to import them from _misc since misc is not informative and is something I'd like to get rid of at some point.

@betatim
Copy link
Member

betatim commented Jun 26, 2023

Ah, looks like I could have figured that out from actually reading the diff ... I skipped it because it was so big :-/

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.

So what are the functions which don't start with _ but are now not available? We should double check those, otherwise LGTM.

@jjerphan
Copy link
Member

Hi @jeremiedbb, is there something blocking this PR or is it ready to be reviewed?

@glemaitre
Copy link
Member

It would need to be sync with main. I am +1 with the spirit of this PR.
I think that once sync we should be quick at merging.

If the function starting with _ are still importable from the top module, then we are not going to break third-library codes that would use those semi-public (developer) functions.

Since we always advocate to have a third-party developer section, I think this need to be done before to go in the documentation where can list which tools are actually useful for third-party libraries.

@jeremiedbb
Copy link
Member Author

Everything has been moved outside of utils.__init__ in individual PRs. We can close this one.

@jeremiedbb jeremiedbb closed this Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Is utils/__init__.py the right place for what's inside ?
5 participants