Scikit-learn

Scikit-learn is a free and open-source machine learning library for Python. It provides a common interface for fitting, transforming, predicting, evaluating, and selecting models, with implementations covering supervised learning, unsupervised learning, preprocessing, feature extraction, and model selection. The project is built around the scientific Python stack, especially NumPy, and is distributed under the BSD 3-Clause license.^[27] Its foundational paper described a focus on established algorithms for medium-scale supervised and unsupervised problems, ease of use, performance, documentation, and API consistency.^[1]

The library's central abstraction is the estimator: an object configured by constructor parameters and trained through a fit method. Predictors add methods such as predict, while transformers add transform. Composite estimators apply the same interface to complete workflows, so preprocessing and a final model can be tuned and evaluated together. This consistency, inspectability, composition, and use of conventional Python data structures were explicit design principles documented by the project.^[2] Scikit-learn is primarily a toolkit for classical machine learning on array-like and tabular data. It is not a general deep-learning, reinforcement-learning, distributed-computing, or experiment-tracking framework.

As of the research cutoff for this article, July 28, 2026, the stable documentation identifies version 1.9.0, released in June 2026, as the current release.^[26] Version-specific behavior should be checked against the documentation for the installed version because defaults, supported input types, experimental APIs, and estimator implementations can change.

History and project scope

David Cournapeau began the project in 2007 as a Google Summer of Code project. Matthieu Brucher worked on it later that year as part of his thesis. In 2010, Fabian Pedregosa, Gael Varoquaux, Alexandre Gramfort, and Vincent Michel of INRIA took leadership, and the first public release was made on February 1, 2010.^[3] The project's 2011 paper in the Journal of Machine Learning Research presented its design goals, underlying technologies, code conventions, and range of learning algorithms.^[1] A 2013 paper examined the API in greater detail, including the estimator, predictor, transformer, meta-estimator, pipeline, and model-selection interfaces.^[2]

Version 1.0.0 was released in September 2021. That release required most optional constructor and function arguments to be passed by keyword, a change intended to make calls clearer and less ambiguous.^[25] The major version number did not convert scikit-learn into a compatibility-guaranteed model format. The project documents backward-compatibility expectations for its public API, but private names may change, deprecations can remove behavior, bug fixes can alter fitted results, and serialized estimators are not promised to work across versions.^[7]

The official project name is written scikit-learn; older names included scikits.learn and scikits-learn.^[4] The package imported in Python is named sklearn.

Scikit-learn deliberately concentrates on established methods that fit its common API. The project states that deep learning and reinforcement learning are outside its scope. It includes a simple multilayer perceptron module, but the project says that module receives bug fixes rather than expansion into a general deep-learning system.^[4] Structured prediction and some sequence-modeling tasks also require representations or interfaces that do not fit the library's present design. The boundary is a project-scope decision, not a claim that those methods are unimportant.

Estimator API

An estimator stores user-selected hyperparameters as constructor parameters and learns from data when fit is called. The constructor should not inspect training data or perform model fitting. Public attributes created during fitting conventionally end in an underscore, such as coef_, classes_, or n_features_in_. Parameters can be inspected with get_params and changed with set_params. The developer documentation specifies these conventions so built-in and third-party estimators can work with pipelines, cloning, and model-selection utilities.^[6]

The main estimator roles are:

Scroll sideways for more →

These roles overlap. A dimensionality-reduction estimator may both fit and transform, while a clusterer may fit and predict cluster assignments. A pipeline is a meta-estimator whose available prediction or transformation methods depend on its final step. The glossary defines common API terms and distinguishes public names from private identifiers beginning with an underscore.^[7]

clone creates an unfitted estimator with the same parameter configuration rather than copying learned attributes. Model-selection tools use this behavior to fit independent estimator instances on different folds or parameter settings. Nested parameter names use a double underscore. For example, a pipeline step named classifier exposes the parameter classifier__C when the final estimator has a parameter named C.^[6][7]

This interface supports composition without requiring every compatible estimator to inherit a deep class hierarchy. The 2013 API paper describes scikit-learn's use of duck typing: an object that follows the expected methods and conventions can participate in many library workflows.^[2] In practice, scikit-learn also supplies base classes, mixins, estimator tags, validation utilities, and common estimator checks to help developers implement compatible objects.^[6]

Data representation and interoperability

Most estimators expect a feature matrix X with rows representing samples and columns representing features. Supervised estimators usually also receive a target array y. Dense inputs are commonly converted to NumPy arrays, while many, but not all, estimators accept sparse matrices or sparse arrays. The matrix-oriented representation allows scikit-learn to reuse optimized numerical operations and gives estimators a common contract.^[2][5]

Array-like input may include Python sequences and numerical pandas data frames, but support is estimator-specific. Most estimators ultimately operate on homogeneous numerical data. String-valued categorical columns therefore usually require encoding, although individual estimators can document exceptions. Sparse input support also varies: an estimator that accepts a sparse matrix can avoid materializing a dense matrix, while an incompatible estimator can reject or densify it. Users should check the documentation for every step in a workflow rather than assuming that one accepted input form is universal.^[4][7]

Fitted estimators can record input feature names in feature_names_in_ when the input provides suitable names. Transformers that implement get_feature_names_out can propagate output names through compatible workflows. By default, transformers generally return NumPy or sparse objects. The set_output API can configure supported transformers to return pandas or Polars data frames, either per estimator or through global configuration. Pandas output was implemented in version 1.2 and Polars output in version 1.4.^[18]

These interfaces do not preserve every property of a source data frame. Index semantics, extension dtypes, nullable values, categorical meaning, and column names can be changed or lost depending on the estimator. A workflow that relies on those properties should test its output containers and feature names explicitly.

Pipelines and composite estimators

Pipeline chains transformers and a final estimator into one object. Calling fit fits each transformer on the training data, transforms the data for the next step, and finally fits the last estimator. A fitted pipeline exposes methods supported by its final step. Pipeline parameters remain searchable through double-underscore names, which permits joint tuning of preprocessing and model parameters.^[8]

The composition API includes several related tools:

• ColumnTransformer applies different transformations to selected columns and concatenates their outputs. It is useful for heterogeneous tabular data, such as numerical and categorical columns.
• FeatureUnion applies transformers in parallel to the same input and combines their outputs.
• TransformedTargetRegressor transforms a regression target for fitting and applies the inverse transformation to predictions.
• Voting, stacking, bagging, calibration, multiclass, and multioutput classes are meta-estimators that wrap other estimators for particular tasks.^[5][8]

A basic mixed-type classification workflow can be expressed as follows:

from sklearn.compose import ColumnTransformer
from sklearn.impute import SimpleImputer
from sklearn.linear_model import LogisticRegression
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import OneHotEncoder, StandardScaler

numeric = make_pipeline(
    SimpleImputer(strategy="median"),
    StandardScaler(),
)
categorical = make_pipeline(
    SimpleImputer(strategy="most_frequent"),
    OneHotEncoder(handle_unknown="ignore"),
)

preprocess = ColumnTransformer(
    [
        ("numeric", numeric, ["age", "income"]),
        ("categorical", categorical, ["region", "plan"]),
    ]
)

model = make_pipeline(
    preprocess,
    LogisticRegression(max_iter=1000),
)
model.fit(X_train, y_train)
predictions = model.predict(X_test)

The important property is not the particular classifier. The transformations are fitted only when the pipeline is fitted. During cross-validation, each training fold gets independently fitted preprocessing. This helps prevent statistics from validation samples from entering scaling, imputation, feature selection, or dimensionality reduction. The common-pitfalls guide identifies pipelines as a primary defense against this form of data leakage.^[9]

A pipeline does not automatically prevent every leak. Leakage can occur before data reaches the pipeline, through target-derived features, duplicate entities split across folds, chronological information from the future, preprocessing performed on the full dataset, or a split strategy that ignores groups. Correct evaluation still depends on defining the prediction problem and partitions appropriately.

Algorithms and tasks

The user guide groups scikit-learn's functionality into supervised learning, unsupervised learning, model selection and evaluation, inspection, dataset transformations, data-loading utilities, and computing support.^[5] The library contains many algorithms, but no one estimator is best for every dataset, metric, or resource constraint.

Supervised learning

Supervised estimators learn from features and known targets. Classification predicts discrete labels, while regression predicts continuous targets. Available model families include linear and generalized linear models, nearest neighbors, support vector machines, decision trees, random forests, gradient boosting, naive Bayes methods, Gaussian processes, discriminant analysis, and simple multilayer perceptrons. Meta-estimators provide multiclass, multilabel, multioutput, probability-calibration, and ensemble strategies.^[5]

Estimator choice depends on more than predictive score. Relevant considerations include the number of samples and features, sparsity, missing values, categorical representation, nonlinear relationships, probability requirements, inference latency, memory, and whether coefficients or decision behavior need to be inspected. Hyperparameters and preprocessing must be treated as part of the evaluated workflow.

Unsupervised and related learning

Unsupervised estimators work without an ordinary target array. The library includes clustering, mixture models, covariance estimation, density estimation, novelty and outlier detection, manifold learning, matrix decomposition, and dimensionality reduction. Common examples include k-means, DBSCAN, Gaussian mixtures, and principal component analysis. Scikit-learn also includes semi-supervised methods that combine labeled and unlabeled samples.^[5]

Outputs from unsupervised methods require domain-aware interpretation. Cluster labels are not ground-truth classes, component directions can change sign without changing a decomposition, and low-dimensional embeddings can distort relationships. Evaluation procedures should match the intended use rather than treating every numerical output as an objective discovery.

Preprocessing, imputation, and feature extraction

Preprocessing transformers include scaling, normalization, categorical encoding, discretization, polynomial features, quantile transformations, and power transformations.^[10] Scaling can be essential for distance-based methods and regularized linear models, but it has a different effect on tree-based estimators. Encoders have specific behavior for unknown categories, output sparsity, and category ordering.

Imputation tools replace missing values using simple statistics, nearest neighbors, indicators, or iterative multivariate estimates. The iterative imputer is documented as experimental. Imputation learns from data, so it should be fitted only on training samples and included inside a pipeline during evaluation.^[11]

Feature-extraction modules convert raw or structured inputs into numerical representations. Text utilities include token-count and term-frequency inverse-document-frequency vectorizers, while hashing-based extractors can operate without retaining a learned vocabulary. Image utilities focus on patch and graph representations rather than a complete computer-vision stack.^[12] Feature selection tools can filter, wrap, or use model-based importance criteria, but selection performed before splitting data can leak information from evaluation samples.

Model selection and evaluation

A held-out test set estimates performance only if it remains untouched until final evaluation. Repeatedly changing a model in response to test results makes the test set part of the development process. Cross-validation instead partitions training data into multiple training and validation folds, leaving a final test set available for a separate assessment.^[13]

Scikit-learn provides splitters for common data structures, including ordinary folds, stratified folds, grouped samples, repeated splits, and time-ordered data. The splitter must reflect the source of dependence in the application. Random folds can be invalid when the same patient, customer, device, document family, or future time period appears in both training and validation partitions. A group-aware or time-aware splitter changes the question being estimated, not merely the syntax of the code.

GridSearchCV evaluates an explicit Cartesian product of parameter values. RandomizedSearchCV samples a fixed number of candidates from parameter distributions. Both can search nested pipeline parameters and refit a selected configuration. Successive-halving search classes allocate increasing resources to a decreasing number of candidates, but the official guide marks those estimators as experimental.^[14] Search results are conditional on the candidate space, scorer, folds, randomization, and compute budget. They do not prove that a globally optimal model was found.

The scoring API includes classification, regression, clustering, ranking, calibration, and loss metrics. A scorer can be selected by name or defined as a callable. Some evaluation and search functions accept multiple scorers at once.^[15] Metric selection should be made before examining final test results and should reflect the consequences of errors. Accuracy can hide poor minority-class behavior, an aggregate regression score can hide subgroup failures, and a probability metric answers a different question from a thresholded decision metric.

Randomness requires care. Passing an integer random_state can make repeated calls reproducible in many contexts, while passing a random-number-generator object can allow its state to be consumed and changed. Cross-validation splitters and stochastic estimators have separate sources of randomness. Reproducibility also depends on package versions, data order, numerical libraries, thread scheduling, and hardware. The project's common-pitfalls guide documents these distinctions.^[9]

Model inspection

The inspection module includes permutation importance, partial dependence, and individual conditional expectation tools.^[16] Permutation importance measures the change in a chosen score after a feature is shuffled. It therefore depends on the fitted model, evaluation data, metric, and correlations among features. It is not an intrinsic causal effect. Partial dependence and individual conditional expectation describe a model's fitted response under particular feature interventions, but correlated or implausible feature combinations can make those plots misleading.

Some estimators also expose coefficients or impurity-based feature importances. Their scale and interpretation depend on preprocessing, regularization, feature coding, and the estimator. Similar names do not make importances comparable across model classes. Inspection can help characterize a fitted model, but it does not establish causal relationships, fairness, robustness, or validity outside the evaluated distribution.

Metadata routing and output configuration

Ordinary estimator methods pass X and, where applicable, y. Workflows can also need metadata such as sample weights or group labels. Metadata routing lets consumers request such values and lets routers, including supported meta-estimators, forward them to the correct method. It is useful when different pipeline components, scorers, or cross-validation splitters need different metadata.^[17]

The metadata-routing API is experimental in version 1.9. It is disabled by default, is not implemented for every meta-estimator, and may change without the usual deprecation cycle. It must be enabled with set_config(enable_metadata_routing=True), and participating consumers explicitly request or reject metadata. The initial API was added in version 1.3; support across prominent workflows expanded in later releases. Code that depends on routing should pin and test its scikit-learn version.^[17]

Output-container configuration is a separate feature. Supported transformers can use set_output(transform="pandas") or set_output(transform="polars"), and the choice can also be set globally. Metadata routing controls extra method arguments; set_output controls transformation result containers. Neither feature means that all estimators operate internally on arbitrary data-frame types.^[18]

Computing, parallelism, and larger data

Scikit-learn uses several forms of parallelism. Some Python-level operations use joblib and expose an n_jobs parameter. Compiled estimator code can use OpenMP, and NumPy or SciPy can call multithreaded BLAS or LAPACK implementations. Because these layers can be nested, setting every layer to use all processors can create more runnable threads than physical CPU resources. The project documentation calls this oversubscription and notes that scheduling overhead can make it slower rather than faster.^[20]

n_jobs=-1 requests all available processors for estimators that implement that parameter; it is not a library-wide switch. Some estimators have no parallel implementation, while others parallelize fitting, prediction, or only selected operations. Process startup, data transfer, memory mapping, and native-library threads all affect performance. Benchmarking the complete workload on representative data is more reliable than assuming that a larger worker count will help.

For data that does not fit in memory, scikit-learn documents an out-of-core pattern with three parts: streaming samples, extracting features, and using an incremental estimator. Estimators that implement partial_fit are candidates, but many estimators do not support incremental learning. Hashing-based feature extraction can avoid storing a vocabulary, while a minibatch balances memory use and computation.^[19] This is a collection of building blocks rather than a transparent distributed execution engine.

Sparse matrices can make high-dimensional problems such as text classification practical, but estimator support and memory behavior vary. A nominally sparse workflow can still become dense after an incompatible transformation. Algorithmic complexity can also dominate: kernel methods, nearest-neighbor searches, covariance operations, and dense decompositions have different scaling limits. Dataset size alone is not enough to predict whether a workflow will fit in memory or finish within a target time.

Array API and GPU support

Scikit-learn does not provide universal graphics processing unit acceleration. Its experimental Array API support allows a limited set of estimators whose computations are expressed through compatible array operations to dispatch to another array namespace. The version 1.9 documentation lists tested combinations including PyTorch, CuPy, and dpnp on selected CPU and GPU devices. The feature must be enabled explicitly, requires an environment setting before importing SciPy and scikit-learn, and does not cover all estimators.^[21]

The project's FAQ explains why this route cannot automatically accelerate every algorithm. Tree implementations and other Cython code can rely on fused low-level operations that are not expressible as a sequence of generic Array API calls. Other estimators can have algorithms or memory-access patterns that do not benefit from a GPU.^[4] Device compatibility, numerical precision, data transfer, and estimator coverage must therefore be checked for the exact version and workflow. A GPU array accepted by one step does not guarantee that a complete pipeline remains on the same device.

Experimental Array API behavior does not carry the ordinary backward-compatibility guarantee. Users should pin versions and test both numerical results and device placement. For workloads centered on neural-network training, automatic differentiation, or custom accelerator kernels, scikit-learn's project scope is different from that of deep-learning frameworks.^[4][21]

Model persistence and deployment

Scikit-learn documents several persistence choices with different goals. Python's pickle, joblib, and cloudpickle can preserve Python objects, but loading data through the pickle protocol can execute arbitrary code. Those formats should be loaded only from trusted sources. skops.io is intended to make the types and objects in an artifact inspectable before loading, although it still requires review. ONNX can support serving some models without a Python environment, but estimator coverage and conversion support vary.^[22]

Persisted estimators should be loaded with the same relevant package versions used for training. Loading a model across scikit-learn versions is unsupported, even if a particular artifact appears to work. A production record should preserve, at minimum, the training code, dependency versions, training-data reference, preprocessing workflow, estimator parameters, evaluation procedure, and any external functions required by the artifact.^[22]

Serialization does not validate the model. Deployment also requires input-schema checks, monitoring, access controls, privacy review, and a response to distribution shift. A pipeline can preserve preprocessing together with an estimator, but it cannot determine whether new data is semantically comparable to its training data.

Governance and maintenance

Scikit-learn describes itself as a meritocratic, consensus-based community project. Contributors can participate in design and decision-making, while core contributors and a Technical Committee have defined responsibilities. The project seeks consensus, with voting and Technical Committee resolution available when consensus cannot be reached. Changes to API principles are generally backed by Scikit-Learn Enhancement Proposals, or SLEPs.^[23]

New algorithms are screened for maturity, documented utility, fit with the existing API, implementation quality, and maintainability. The FAQ gives a rule of thumb of at least three years since publication, more than 200 citations, and broad usefulness, while allowing clear improvements to established methods. These are inclusion criteria, not a guarantee that every included algorithm is appropriate for a particular dataset.^[4]

The project maintains public API conventions and commonly uses deprecation warnings before removals. Experimental features can explicitly opt out of the normal deprecation cycle. Users maintaining long-lived systems should read version release notes, treat warnings as migration signals, and test model behavior when upgrading. A successful import or unpickle is not sufficient evidence that numerical behavior is unchanged.^[7][22]

Version 1.9 snapshot

Scikit-learn 1.9.0 was released in June 2026.^[26] Its release notes describe a new experimental callback API for compatible estimators, with built-in ProgressBar and ScoringMonitor callbacks. The initial support list includes selected estimators and meta-estimators rather than every fit implementation. The same release introduced a sparse_interface configuration option that controls whether supported outputs use SciPy sparse matrices or sparse arrays, initially defaulting to sparse matrices.^[26]

These features illustrate why examples should state the scikit-learn version they target. Callback availability, sparse output types, defaults, and deprecations can affect code without changing the underlying machine-learning task. The release notes are the authoritative inventory of changes; a short article cannot substitute for their estimator-by-estimator detail.

Installation and operational practice

The official installation guide recommends the latest stable release for most users and strongly recommends an isolated environment. It documents installation with pip and conda-forge, as well as source and nightly builds for development or pre-release testing.^[24] A minimal pip workflow is:

python -m venv sklearn-env
source sklearn-env/bin/activate
python -m pip install -U scikit-learn
python -c "import sklearn; sklearn.show_versions()"

The exact supported Python and dependency versions change over time. Environment resolution should therefore use the installation documentation for the selected scikit-learn release. Recording sklearn.show_versions() can assist debugging, but a reproducible environment also needs a lock file, container image, or equivalent dependency record.

For production work, the complete workflow should be tested after dependency upgrades. Tests should cover preprocessing output shape and feature order, accepted missing values and categories, prediction semantics, scoring conventions, serialization and reload, concurrency, and resource usage. Estimator defaults are starting points, not evidence that a model is accurate, calibrated, fair, robust, or suitable for deployment.

Limitations and appropriate interpretation

Scikit-learn supplies algorithms and evaluation tools; it does not define the target, collect representative data, remove bias, select the correct metric, or make a result causal. Data leakage, label errors, selection bias, dependence between samples, distribution shift, and poorly chosen validation splits can invalidate a technically correct program. The common estimator interface makes experiments easier to express, but it does not make different models equivalent or automatically comparable.

The library is strongest when a problem can be represented as fixed-size samples with numerical or encoded features and can be handled on one machine or through supported incremental methods. Deep neural architectures, reinforcement learning, arbitrary structured outputs, general distributed training, and universal GPU execution are outside or only partially within its scope.^[4][19][21]

Results should be reported with the data partitioning rule, preprocessing, estimator class, all material hyperparameters, scorer, uncertainty across folds or repeated runs where appropriate, package versions, and final held-out evaluation. Claims about one algorithm being faster or more accurate should be limited to the measured dataset, hardware, software versions, metric, and search budget.

See also

• Supervised learning
• Unsupervised learning
• Feature engineering
• Cross-validation
• Hyperparameter
• Deep learning
• Reinforcement learning
• Data science

References

1. ^Pedregosa, F., et al. "Scikit-learn: Machine Learning in Python." *Journal of Machine Learning Research* 12 (2011): 2825-2830. jmlr.org/...pedregosa11a
2. ^Buitinck, L., et al. "API design for machine learning software: experiences from the scikit-learn project." ECML PKDD Workshop: Languages for Data Mining and Machine Learning (2013). arxiv.org/...1309.0238
3. ^Scikit-learn developers. "About us: History." Scikit-learn 1.9.0 documentation. scikit-learn.org/...about
4. ^Scikit-learn developers. "Frequently Asked Questions." Scikit-learn 1.9.0 documentation. scikit-learn.org/...faq
5. ^Scikit-learn developers. "User Guide." Scikit-learn 1.9.0 documentation. scikit-learn.org/...user_guide
6. ^Scikit-learn developers. "Developing scikit-learn estimators." Scikit-learn 1.9.0 documentation. scikit-learn.org/...develop
7. ^Scikit-learn developers. "Glossary of Common Terms and API Elements." Scikit-learn 1.9.0 documentation. scikit-learn.org/...glossary
8. ^Scikit-learn developers. "Pipelines and composite estimators." Scikit-learn 1.9.0 documentation. scikit-learn.org/...compose
9. ^Scikit-learn developers. "Common pitfalls and recommended practices." Scikit-learn 1.9.0 documentation. scikit-learn.org/...common_pitfalls
10. ^Scikit-learn developers. "Preprocessing data." Scikit-learn 1.9.0 documentation. scikit-learn.org/...preprocessing
11. ^Scikit-learn developers. "Imputation of missing values." Scikit-learn 1.9.0 documentation. scikit-learn.org/...impute
12. ^Scikit-learn developers. "Feature extraction." Scikit-learn 1.9.0 documentation. scikit-learn.org/...feature_extraction
13. ^Scikit-learn developers. "Cross-validation: evaluating estimator performance." Scikit-learn 1.9.0 documentation. scikit-learn.org/...cross_validation
14. ^Scikit-learn developers. "Tuning the hyper-parameters of an estimator." Scikit-learn 1.9.0 documentation. scikit-learn.org/...grid_search
15. ^Scikit-learn developers. "Metrics and scoring: quantifying the quality of predictions." Scikit-learn 1.9.0 documentation. scikit-learn.org/...model_evaluation
16. ^Scikit-learn developers. "sklearn.inspection." Scikit-learn 1.9.0 documentation. scikit-learn.org/...sklearn.inspection
17. ^Scikit-learn developers. "Metadata Routing." Scikit-learn 1.9.0 documentation. scikit-learn.org/...metadata_routing
18. ^Scikit-learn developers. "Pandas/Polars Output for Transformers with set_output API." Scikit-learn 1.9.0 documentation. scikit-learn.org/...df_output_transform
19. ^Scikit-learn developers. "Strategies to scale computationally: bigger data." Scikit-learn 1.9.0 documentation. scikit-learn.org/...scaling_strategies
20. ^Scikit-learn developers. "Parallelism, resource management, and configuration." Scikit-learn 1.9.0 documentation. scikit-learn.org/...parallelism
21. ^Scikit-learn developers. "Array API support (experimental)." Scikit-learn 1.9.0 documentation. scikit-learn.org/...array_api
22. ^Scikit-learn developers. "Model persistence." Scikit-learn 1.9.0 documentation. scikit-learn.org/...model_persistence
23. ^Scikit-learn developers. "Scikit-learn governance and decision-making." Scikit-learn 1.9.0 documentation. scikit-learn.org/...governance
24. ^Scikit-learn developers. "Installing scikit-learn." Scikit-learn 1.9.0 documentation. scikit-learn.org/...install
25. ^Scikit-learn developers. "Version 1.0." Scikit-learn 1.9.0 documentation. scikit-learn.org/...v1.0
26. ^Scikit-learn developers. "Version 1.9." Scikit-learn 1.9.0 documentation. scikit-learn.org/...v1.9
27. ^Scikit-learn developers. "BSD 3-Clause License." Scikit-learn source repository. github.com/...COPYING