Fix missing and fragile scikit-learn imports in Keras sklearn wrappers

[timovdk]

This PR addresses a bug where the SKLearnClassifier and SKLearnRegressor wrappers raise an AttributeError when used without other scikit-learn utilities (e.g. make_classification).

Fixes

• Explicitly imports sklearn.utils.multiclass.type_of_target instead of relying on indirect access via sklearn.utils
• Cleans up related imports in related files:
  • Replaces several indirect accesses with explicit imports (make_pipeline, OneHotEncoder, MetadataRequest, check_is_fitted)
  • Avoids the use of private API sklearn.utils._array_api by using np.squeeze directly, which is consistent with the docstring expectations

Related Issue

Fixes #21386

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.67%. Comparing base (764ed95) to head (4df855e).
Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #21387   +/-   ##
=======================================
  Coverage   82.67%   82.67%           
=======================================
  Files         565      565           
  Lines       55064    55068    +4     
  Branches     8569     8569           
=======================================
+ Hits        45525    45529    +4     
  Misses       7441     7441           
  Partials     2098     2098           

Flag	Coverage Δ
keras	82.48% <100.00%> (+<0.01%)	⬆️
keras-jax	63.51% <100.00%> (+<0.01%)	⬆️
keras-numpy	58.68% <66.66%> (+<0.01%)	⬆️
keras-openvino	33.46% <66.66%> (+<0.01%)	⬆️
keras-tensorflow	63.91% <100.00%> (+<0.01%)	⬆️
keras-torch	63.54% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fchollet]

Thanks for the PR.

where the SKLearnClassifier and SKLearnRegressor wrappers raise an AttributeError when used without other scikit-learn utilities (e.g. make_classification).

Why does this happen exactly?

It's generally much cleaner to only try to import sklearn.

[timovdk]

Thanks for the PR.

where the SKLearnClassifier and SKLearnRegressor wrappers raise an AttributeError when used without other scikit-learn utilities (e.g. make_classification).

Why does this happen exactly?

It's generally much cleaner to only try to import sklearn.

Thanks for the review!

The issue is that import sklearn alone does not load submodules like sklearn.utils.multiclass. So when code later accesses sklearn.utils.multiclass.type_of_target it can raise an AttributeError because utils or multiclass hasn't been imported yet. This doesn't show up in the docstring examples, since those import make_classification, which indirectly imports the multiclass (and other .utils) submodules.

Switching to directly importing type_of_target ensures that missing dependencies raise an ImportError at import time. However, to raise the ImportError consistently, I agree that import sklearn should be re-added to these files, thanks!

[fchollet]

The issue is that import sklearn alone does not load submodules like sklearn.utils.multiclass. So when code later accesses sklearn.utils.multiclass.type_of_target it can raise an AttributeError because utils or multiclass hasn't been imported yet

This is an issue with the design of sklearn; if the package was well-designed then you could access any member of the API from sklearn.xyz... (as is the case for Keras).

To route around it I would suggest leaving the top-of-file import structure unchanged, and then doing e.g. from sklearn.utils.validation import check_is_fitted right before you need it, in-line.

[timovdk]

This is an issue with the design of sklearn; if the package was well-designed then you could access any member of the API from sklearn.xyz... (as is the case for Keras).

Yes I agree, and this is only the case for multiclass, which is not exposed in sklearn/utils/__init__.py. That's why type_of_target cannot be accessed through sklearn.utils.multiclass.type_of_target.

After fixing that import, I adjusted the other sklearn imports for consistency by using the same from sklearn.xyz import foo style and grouping them at the top of the file for readability.

But, if the preference is to use inline imports, I propose to revert all non-essential import changes and leave only the inline import for type_of_target, because I think that the readability argument no longer applies with inline imports.

(Edit): I also found that check_is_fitted is not exposed through sklearn/utils/__init__.py, so it too would require an inline import. The others (metadata_routing, preprocessing, and pipeline) are exposed through their respective __init__.py files, so I can safely revert those changes.

[fchollet]

LGTM, thanks for the update!