Skip to main content

mlxlearn

Classical machine learning on Apple silicon, accelerated with MLX, with a scikit-learn compatible API.

mlxlearn is not officially associated with scikit-learn or PROBABL, nor with Apple.

mlxlearn has two layers.

Layer 1 — the library. Explicit imports, typed solver configuration and state, strict errors, eager fit, no mutation of scikit-learn, no data-keyed caches:

from mlxlearn.neighbors import KNeighborsClassifier

clf = KNeighborsClassifier(n_neighbors=5).fit(X_train, y_train)
y_pred = clf.predict(X_test)

Layer 2 — the patching shell. A thin adapter that points scikit-learn's own names at Layer 1 estimators, so existing code — including code an LLM generated against the scikit-learn API — runs accelerated without being edited:

from mlxlearn import patch_sklearn
patch_sklearn()

from sklearn.svm import SVC          # now resolves to the accelerated class

The numerical library is fully usable and fully tested with the patching mechanism absent.

Direct KNN classes use sklearn's public estimator interface without inheriting its concrete neighbor classes, avoiding those imports during ordinary startup. isinstance against a stock neighbor class is therefore false for direct KNN objects. Use their own graph methods; sklearn's standalone graph helpers do not accept these objects as fitted-estimator inputs. Patched KNN classes retain stock inheritance. See the compatibility details.

Status

0.1.1 — alpha. The API may change. See CHANGELOG.md.

Estimator Status
mlxlearn.neighbors.NearestNeighbors 0.1.0
mlxlearn.neighbors.KNeighborsClassifier 0.1.0
mlxlearn.neighbors.KNeighborsRegressor 0.1.0
mlxlearn.linear_model.LogisticRegression 0.1.0
mlxlearn.svm.SVC (exact) 0.1.0
LinearRegression, Ridge, PCA, KMeans, DBSCAN, TSNE planned, 0.2.x
SVR, NuSVR, NuSVC deferred — will not ship until they implement the true objective
tree ensembles out of scope

Requirements

  • macOS on Apple silicon (arm64)
  • Python 3.10 – 3.13
  • scikit-learn ≥ 1.7, MLX ≥ 0.29

Python 3.10 is supported with scikit-learn 1.7.x; scikit-learn 1.8+ requires Python ≥ 3.11. CI tests only valid pairs — see docs/support_matrix.md.

Install

pip install mlx-learn

Version 0.1.1 builds on Apple silicon can include optional Metal and C++ CPU extensions. The CPU extension handles small KNN workloads and is compiled at build time; fitting or querying never invokes the C++ compiler. A compatible wheel includes the extensions built into it. Without a compiler or CPU extension, the certified portable CPU implementation remains available with the same ordering contract; native-build benchmark timings do not describe that fallback's performance.

The CPU module uses the full CPython C API, so wheels containing it target a specific Python minor version. The Metal component itself retains its stable abi3 interface. Installing a compatible prebuilt wheel needs no compiler.

Import-order semantics

Patching replaces attributes on scikit-learn modules. Attribute access (sklearn.svm.SVC) therefore resolves to the mlxlearn class whether import sklearn happened before or after patch_sklearn().

Symbols captured before patching are local bindings and cannot be rebound:

from sklearn.svm import SVC     # binds the stock class into your namespace
patch_sklearn()                 # cannot reach back and change SVC
SVC()                           # still the stock class

That is Python name binding, not a bug in mlxlearn. The supported pattern is patch-first. patch_sklearn() is idempotent, and unpatch_sklearn() fully restores scikit-learn.

When mlxlearn falls back

Layer 1 raises a precise error when it cannot honor a request. Layer 2 falls back to stock scikit-learn instead — but only for capability mismatches (sparse input, an unsupported parameter, an unsupported dtype), never to hide a bug:

Situation Direct import Patched
Capability mismatch precise MLXLearnError falls back, warns once per class, records diagnostics
KNN with device="auto" owned CPU/GPU search owned CPU/GPU search
Other estimators below the measured crossover internal CPU path dispatches to scikit-learn
Invalid user input sklearn-equivalent validation error scikit-learn's own exception, unmasked
Unexpected backend runtime failure raises raises — never silently rerun on scikit-learn

Set the policy with fallback_policy="warn" | "raise" | "silent". Diagnostics are recorded in every mode:

import mlxlearn

with mlxlearn.config_context(fallback_policy="raise"):
    ...                                     # any capability fallback becomes an error

mlxlearn.get_last_backend_event()           # what the last fit/predict actually did
mlxlearn.get_backend_diagnostics()          # everything recorded this session

Sticky fitted policy. execution_backend_ records the fit backend ("mlx", "cpu", or "sklearn"). Inference reuses that backend, except for NumPy KNN estimators fitted with device="auto": their execution_policy_ is "auto", allowing each query batch to use the owned CPU or GPU search. Small datasets and single queries can avoid GPU launch overhead, while larger batches retain the GPU path. last_query_backend_ and backend diagnostics report the actual search. Explicit KNN device choices use a "fixed" policy. Changing global configuration after fit does not alter either fitted policy, and automatic CPU search does not invoke a scikit-learn solver. A new fit clears state and may choose differently.

Configuration

The public surface is deliberately small:

mlxlearn.set_config(
    device="auto",              # "auto" | "gpu" | "cpu"
    fallback_policy="warn",     # "warn" | "raise" | "silent"
    output_type="numpy",        # 0.1.0: NumPy in, NumPy out
    deterministic=True,
    random_state=0,
    diagnostics=True,
)

Crossover thresholds, block sizes, and solver tuning are private, typed, and overridable only through MLXLEARN_* environment variables for CI and debugging. They are not part of the public API.

Performance

The latest rerun of the original three tall datasets measures complete float32 GPU fits at 6.30 ms (500,000 × 32), 13.20 ms (500,000 × 128), and 13.01 ms (60,000 × 1,024): 11.8×, 5.8× and 2.7× stock sklearn on the measured M4 Max. Every timed fit passed independent accuracy checks. The two narrow cases gained from one fused line-search pass and one input pipeline for every feature count; the earlier recheck records the previous timings and the exact settings, variability and limits of the historical comparison.

The development version uses native Metal C++ kernels for binary GPU logistic regression, including optimizer history, batched line search, and matrix reductions. Wide fits fuse candidate losses and the likely accepted gradient into one matrix pass. Wide-input preparation also combines validation, centering, and initial gradient statistics, while large contiguous float64 inputs use a checked parallel conversion. See the earlier overhead comparison for complete fresh-fit timings against the frozen previous implementation and stock scikit-learn, including timing variability and numerical quality. In that earlier comparison the 20,000 × 1,024 float32 case reached 1.68× sklearn; larger cases benefited more. Reproduce it with:

python -m benchmarks.logistic_wide \
  --reference-archive benchmarks/reference/wide-logistic-2026-10-26.zip \
  --profile full --dtype both --repeats 30 --warmup 3 --threads 1

The previous wide comparison records the matrix kernel changes and the pre-existing 4,096-feature objective-parity limitation. The development version also includes an optional native Metal command loop for prepared wide binary fits on MLX 0.32.x. It retains input buffers through GPU completion and falls back to the established solver when unavailable. See the native loop results for warm and first-fit timings, numerical checks, supported inputs, and limitations. The preceding native comparison records the earlier tall-data improvements and small-data limitations.

Development work also corrects logistic convergence checks for centered inputs: the stopping gradient is evaluated in the original feature coordinates. For inputs at risk of float32 rounding error, a selective CPU float64 pass checks the returned model against the original input; it is a certificate, not a second solver. Its trigger is heuristic and does not cover every possible rounding error. Some severely shifted multinomial stress cases still report nonconvergence at the requested tolerance. A two-step wide-model loss-progress heuristic addresses an observed 4,096-feature objective gap; it also is not a guarantee of objective parity. The speed results linked above are historical, before these convergence changes. The revised solver's targeted benchmarks show 12.9–14.1% slower 4,096-feature fits than the frozen baseline. See the convergence investigation for evidence, limitations and the broader benchmark.

The experimental mlxlearn_device.fit_logistic interface accepts and returns MLX arrays without importing NumPy or scikit-learn. It supports binary float32 inputs on the tested Metal bridge and can initialize L-BFGS from GPU Hessian-sketch curvature pairs. The sklearn-compatible path exposes the sketch as an opt-in private tuning setting. The device convergence check is compensated GPU arithmetic, not a formal error bound; the runtime API, supported inputs and accuracy limitations are described in the device and Hessian-sketch report.

The preceding sketch and weighted investigation measures a scheduling improvement for long fits and records the unbalanced-data objective gap found under the earlier gradient stopping rule. The follow-up weighted accuracy report describes the additional progress safeguard, its cost and its limits, and the wide GPU candidates evaluated against the starting implementation. The wide accuracy and device-sketch report documents the subsequent ordinary 4,096-feature improvement, the device retry fix, and the remaining strongly correlated accuracy gap. The ill-conditioned solver investigation examines that unresolved gap and a private GPU Hessian-vector building block. That investigation enabled no new solver. The subsequent cooperative L-BFGS and guarded Newton report describes the implemented parallel direction recurrence and bounded Newton refinement for strongly scale-skewed wide inputs. The final standard panel measures 30.24 ms versus sklearn's 65.52 ms on 20,000 × 4,096 ordinary inputs, and independent references confirm the reproduced ill-conditioned and weighted accuracy fixes. General rank-deficiency checks pass; the report records cases without a speed win, reference limitations and full-suite validation status.

SVC uses native C++ hierarchical working sets and pairwise SMO with active-set shrinking, preserving float64 optimizer state and float32 kernel rows. GPU kernel transforms and requested row batches use fused Metal kernels. Prepared support vectors and norms are reused for prediction with exact mutation checks. Native CPU routines handle statistics, decision reductions and multiclass voting; NumPy remains at the validation and public-array boundary, with portable fallbacks if the optional extensions are unavailable. Automatic backend thresholds remain conservative. See the working-set implementation and benchmarks and the earlier native-loop acceleration.

KNN shares a NumPy-free GPU search core with mlxlearn_device.fit_neighbors. Small neighbor counts use fused Metal distance/selection kernels, and GPU classifier search and voting stay on the device until the final output. Automatic NumPy KNN also has an owned CPU search and host voting for latency-sensitive queries; the native device API retains explicit device execution. The sklearn API retains its NumPy outputs and float64 regression target arithmetic. See the KNN implementation and benchmark report. The compact-search pass reaches 2.10–3.02× default-thread sklearn across all 54 search/inference operation–dataset medians in two runs on 50,000 training rows, 32 features, 256 queries and k=5. Fresh fit plus query is included. Compact storage and bounded shortlists reduce search work while exact refinement and fallback preserve the preceding float32 results. The report includes every implemented benchmark operation, the previous version, single-thread and default-thread sklearn, per-call variability and fit-only costs. Earlier acceleration and packed-load reports retain their original target misses and distinguish intermittent calls from fully warmed operation. The subsequent integer filter now uses a cached training-data guard to retain compact search when feature variation is concentrated. The regression-fix report compares both Gaussian and unequal-scale data against v3, including fresh-fit costs and identical-code controls. The guard does not rescale the requested metric. A subsequent input-validation optimization removes the residual unequal-scale fresh fit-plus-query slowdown while retaining the Gaussian gains; the report includes frozen-v3 reruns and validation checks. The precision and ordering fix resolves rounded-distance ties and Gram candidate loss using certified screening and adaptive original-coordinate comparisons. It includes the full v3 rerun and retains benchmark failures in the comparison baselines. The 128-feature optimization combines shortlist refinement, ordering and certification while preserving the precision fixes; it includes controlled comparisons with v3 and the prior precision build. The pre-fix broader sklearn comparison covers 72 dataset instances and nine search/inference operations. That GPU build reaches 2× default-thread brute sklearn on 402/648 medians, but the gain is workload-dependent: large Gaussian and unequal-scale batches perform well, while small datasets, clustered data and some offset cases miss the target. The report includes single-thread and automatic-algorithm sklearn baselines, every retained timing, and separate precision/tie audits. The clustered/offset fix uses cached distribution routing and guarded exact centering for screening. All 108 targeted dataset-operation medians now beat all three sklearn configurations; the full panel reaches 2× on 482/648 medians against default-thread brute and 524/648 against auto. Gaussian gains and precision checks remain; the report quantifies small fresh-fit costs and workloads that still favor sklearn. The Gaussian fresh-fit fix removes the remaining 128-feature setup regression by evaluating compiled Gram preparation with the first query. Fresh fit-plus-query is 1.20–1.28× faster than the pre-regression build across six controlled seeds; clustered/offset gains and all precision checks hold. The full 72-instance sklearn rerun reaches 2× on 492/648 default-brute, 246/648 single-thread-brute and 528/648 auto medians. All 108 clustered/offset medians beat all three configurations. The preceding small-workload GPU optimization combines selection and precision certification in one launch and trims query validation overhead. All 162 targeted controlled comparisons improve by paired median (1.08–1.48× versus the preceding build). The full panel reaches 2× on 526/648 default-brute, 252/648 single-thread-brute and 551/648 auto medians, with all 14,472 accuracy audits passing. In that fixed-GPU run, only 5/162 targeted medians beat single-thread sklearn. The preceding automatic CPU/GPU dispatch introduced an owned, exact-order CPU search for suitable small and single-query workloads. That run recorded 162/162 targeted wins against each sklearn configuration, a narrowest win of 1.010×, and 1,025 passing tests.

The preceding latency fix added native integer selection, faster feature-range preparation and deferred GPU probing. That run improved all 27 warmed Digits cells 1.82–2.45× over its predecessor, but total process startup beat sklearn auto on only 7/18 fixtures.

The preceding startup revision avoids loading unused stock neighbor implementations during direct owned search and retains the native CPU improvements. All 162 targeted and 108 clustered/offset medians beat all three sklearn configurations. All 14,472 current broad accuracy audits and 1,473 distinct checks pass: 1,408 relevant tests, also rerun on sklearn 1.7, 1.8 and 1.9, plus 65 harness checks.

In the 450-process cold panel, all 18 fixtures have 15–18% lower process-to-result medians than the three sklearn configurations, with imports and native loading included. All 18 also beat the preceding automatic build by 1.181–1.213×. First-query and fit-plus-query medians beat sklearn on all 18, but improve over the preceding automatic build on only 14/18 and 17/18, respectively. The balanced implementation control wins all 162 target cells against both GPU implementations; its legacy-order repeat retains one Digits slowdown against the older GPU build: 2.1% by median paired ratio and 3.7% by ratio of medians. These measured gains do not imply a universal 2× speedup or zero regressions.

The separate 2,700-fresh-model panel tests first use after normal process initialization. All 18 first-query and fit-plus-first-query medians beat all three sklearn configurations and preceding automatic. Against preceding automatic, the speedups are 1.019–1.234× for first query and 1.152–1.574× for combined fit and first query.

The latest Digits revision combines integer dot validation and exact top-five selection in one native pass. It removes the remaining Digits GPU-control miss: 432/432 comparisons across both GPU baselines, replicas, statistics and control orderings are faster, with a minimum 1.047× speedup. The previously failing weighted-regression cell is now 1.051× paired / 1.079× ratio-of-medians versus historical GPU. All 162 small/single-query, 108 clustered/offset and 81 explicit Gaussian-distribution broad cells still beat all three sklearn settings. All 18 startup and first-query fixture medians also beat those settings.

The revision passes 1,474 relevant tests on each of sklearn 1.7, 1.8 and 1.9, plus 65 harness checks and 14,472 current broad numerical audits. It does not establish zero regression versus the preceding automatic build: three Breast Cancer slowdowns recur in separate-worker controls, and some small first-query medians remain slower. An additional exact-native A/B/A probe did not reproduce the large Breast losses; all observations and that test's limits are retained in the report. The 1.10× Digits margin target passes 46/48 checks, while all 432 above-parity checks pass.

import mlx.core as mx
from mlxlearn_device import fit_neighbors

index = fit_neighbors(mx.array([[0., 0.], [1., 1.], [2., 2.]]))
distances, indices = index.query(mx.array([[0.2, 0.1]]), k=2)
mx.eval(distances, indices)  # results remain MLX arrays

Performance depends on training size, feature count, query batch, neighbor count and data distribution. Automatic KNN selects its owned CPU or GPU search under the policy captured at fit; explicit device choices remain fixed. The linked reports include complete timings, variability and workloads where sklearn remains faster. Other patched solvers can hand small problems to scikit-learn.

What that means for the measured development build on an M4 Max:

Neighbor queries/inference Wins 625/648, 648/648 and 648/648 medians against default brute, single-thread brute and auto sklearn on the full panel. The ≥2× counts are 587, 300 and 592, respectively.
Neighbor fit and startup Owns training data and defers search preparation where appropriate. Fit-only, first fit-plus-query and total process startup are reported separately; query gains do not guarantee faster fit or startup.
SVC Native working sets improve measured linear and RBF fits; tiny-cache RBF still trails sklearn and prediction gains vary. See the current results and limitations. Patched routing remains conservative, and linear is excluded from automatic GPU selection.
LogisticRegression Faster than scikit-learn on large problems: 11.8×, 5.8× and 2.7× for binary fits at 500,000 × 32, 500,000 × 128 and 60,000 × 1,024 (fused-kernel rerun), and 6.4–12.8× for converged 10-class fits at 60,000 × 784 (MNIST family). Patched dispatch still hands small problems to scikit-learn, which was faster there when last measured. It uses MLX only from 20,000 samples and 2×10⁷ elements, or from 250,000 samples and 8×10⁶ elements. The historical small-problem measurements explain the per-iteration overhead behind that threshold.

Reproduce them:

python -m benchmarks.run --profile smoke

MNIST, Fashion-MNIST and Kannada-MNIST

The three 10-class image datasets are 60,000 training rows × 784 pixels each. Pixels are scaled to [0, 1] and estimator parameters are left at their defaults unless noted. MNIST and Fashion-MNIST validate on their 10,000-row test sets. Kannada-MNIST's Kaggle test.csv is unlabeled, so it validates on the 10,240-row Dig-MNIST set. Dig-MNIST was written by different people and is much harder: both libraries reach about 98% training accuracy on Kannada-MNIST but score far lower on it.

These shapes clear the automatic thresholds, so patch_sklearn() runs all three estimators on MLX as well. Measured 2026-11-02 at c928419 on an M4 Max (12+4 CPU cores, 40-core GPU, 128 GB) with Python 3.14.2, scikit-learn 1.9.1, MLX 0.32.4 and NumPy 2.5.4. First-use kernel compilation is excluded from every timing.

LogisticRegression, run to convergence (max_iter=5000, default tol=1e-4). Times are medians of 5 fits, with float32 input for mlxlearn and float64 for scikit-learn.

Dataset mlxlearn fit sklearn fit Speedup L-BFGS iterations, mlxlearn / sklearn Test accuracy, mlxlearn / sklearn
MNIST 0.25 s 3.14 s 12.8× 108 / 247 92.60% / 92.60%
Fashion-MNIST 1.28 s 8.20 s 6.4× 313 / 653 85.24% / 85.26%
Kannada-MNIST (Dig-MNIST) 0.14 s 1.17 s 8.2× 63 / 93 59.81% / 59.87%
  • Convergence: both libraries reach the tolerance on all three datasets, checked with an independent float64 evaluation of scikit-learn's objective and gradient. The final objectives agree to within 0.4%, mlxlearn's being lower on two of the three. Predictions agree on 98.6–99.8% of validation rows.
  • Default max_iter=100: MNIST and Fashion-MNIST stop unconverged in both libraries. mlxlearn fits 4.9× and 4.6× faster there and stops at a lower objective.
  • Prediction: predict costs the same in both (about 2 ms per 10,000 rows) because inference uses scikit-learn's own code.

KNeighborsClassifier (n_neighbors=5). Predict times are the best and the median of 7 calls on the full validation set. mlxlearn gets float32 input and scikit-learn gets float64 input, its faster setting here.

Dataset mlxlearn predict sklearn predict Speedup (best) Test accuracy, both
MNIST 0.11 s / 0.14 s 1.28 s / 1.31 s 11.4× 96.88%
Fashion-MNIST 0.11 s / 0.11 s 1.22 s / 1.25 s 11.0× 85.89%
Kannada-MNIST (Dig-MNIST) 0.11 s / 0.11 s 1.25 s / 1.28 s 11.7× 71.46%
  • Exactness: the raw pixels are integers, so exact squared distances are available for every pair. Every returned neighbor set, from both libraries with both float32 and float64 input, was audited against them and is exact on all three datasets.
  • Predictions: identical everywhere. On one Fashion-MNIST row, the two libraries break an exact distance tie at the 5th neighbor differently.
  • Fit: fitting stores the training data and takes 8–13 ms in both libraries.

SVC (RBF kernel, C=1, gamma="scale"). mlxlearn times are medians of 3 fits and scikit-learn times are single fits.

Dataset mlxlearn fit, 200 MB / 2,000 MB cache sklearn fit Fit speedup mlxlearn predict sklearn predict Predict speedup Test accuracy, mlxlearn / sklearn Support vectors, mlxlearn / sklearn
MNIST 12.5 s / 5.6 s 122 s 9.8× / 21.7× 0.09 s 26.6 s 298× 97.92% / 97.92% 12,334 / 12,336
Fashion-MNIST 13.6 s / 5.7 s 167 s 12.3× / 29.5× 0.17 s 45.0 s 263× 89.21% / 89.21% 20,816 / 20,823
Kannada-MNIST (Dig-MNIST) 10.2 s / 5.2 s 118 s 11.6× / 22.6× 0.09 s 24.7 s 271× 68.01% / 68.00% 11,180 / 11,180
  • Cache size: raising cache_size to 2,000 MB does not change scikit-learn's fit time (122.5 s, 166.2 s and 117.5 s).
  • Predictions: identical on MNIST and Fashion-MNIST, and 2 of 10,240 differ on Dig-MNIST. At most 0.21% of rows have a pairwise decision with the opposite sign from scikit-learn's.
  • Decision values: summed one-vs-one decision values differ by a median of 2–4×10⁻⁴ (at most 2.6×10⁻³). That is consistent with tol=1e-3 and float32 kernel rows.

Three unrelated single-threaded processes and other applications' GPU work (about 19% GPU utilization at idle) were running throughout. Under that load, back-to-back mlxlearn KNN predictions on MNIST varied between 0.11 and 0.22 s.

Precision

MLX computes in float32 on the GPU. mlxlearn's parity tests are written to float32 tolerances, and the cases where float32 makes strict scikit-learn equivalence impossible are enumerated — not waved away — in docs/fp32_policy.md.

Development

pip install -e ".[dev]"
python3 setup.py build_ext --inplace
pytest

Rebuild the extensions with python3 setup.py build_ext --inplace after changing their C++ or Objective-C++ sources. The optional native CPU search uses bounded float32 screening, float64 output distances, Neon on arm64, and exact 640-bit dyadic keys for ambiguous ordering. The portable certified path remains available when that extension was not built; 64-feature integer batches retain their exact Gram path.

Reproducing native benchmark results from a source archive requires building its extension or restoring the archived binary for the exact matching Python ABI, operating system, and architecture. The source-only portable fallback remains supported and tested for precision, but is not the measured native configuration.

Contributor rules, the estimator gate checklist, and the compliance checks are in docs/development.md.

Provenance

mlxlearn succeeds a private research fork of an Intel-maintained scikit-learn accelerator. That history is not carried here: this repository was bootstrapped from an audited allowlist, and no source file was copied. The audit, the recorded behavioral baseline of the ancestor, and the authorship attestation are in phase0/. Full lineage, disclaimers, and third-party notices are in ACKNOWLEDGMENTS.md and THIRD_PARTY_NOTICES.md.

License

Apache-2.0. See LICENSE.

Metadata

Release files for mlx-learn 0.1.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for mlx-learn 0.1.1
File Size Uploaded Provenance Actions
mlx_learn-0.1.1.tar.gz 267.4 kB With provenance Details for mlx_learn-0.1.1.tar.gz

Built distributions (wheels)

Table of built distributions (wheels) for mlx-learn 0.1.1
File Actions
mlx_learn-0.1.1-cp313-cp313-macosx_11_0_arm64.whl CPython 3.13 CPython 3.13 macOS 11.0+ ARM64 Details for mlx_learn-0.1.1-cp313-cp313-macosx_11_0_arm64.whl
mlx_learn-0.1.1-cp312-cp312-macosx_11_0_arm64.whl CPython 3.12 CPython 3.12 macOS 11.0+ ARM64 Details for mlx_learn-0.1.1-cp312-cp312-macosx_11_0_arm64.whl
mlx_learn-0.1.1-cp311-cp311-macosx_11_0_arm64.whl CPython 3.11 CPython 3.11 macOS 11.0+ ARM64 Details for mlx_learn-0.1.1-cp311-cp311-macosx_11_0_arm64.whl
mlx_learn-0.1.1-cp310-cp310-macosx_11_0_arm64.whl CPython 3.10 CPython 3.10 macOS 11.0+ ARM64 Details for mlx_learn-0.1.1-cp310-cp310-macosx_11_0_arm64.whl

Total release size: 1.9 MB

Release files / mlx_learn-0.1.1.tar.gz

Download URL mlx_learn-0.1.1.tar.gz
Size 267.4 kB
Tags Source
SHA-256 checksum
How to use checksums
ad15499cacf02c1dfc02f6a31bebecc033a39070cff8e5611bc1b98e3ef37094
BLAKE2b-256 checksum
How to use checksums
b895061984cedf9cbcde35a13ee4873dc2e839dabe54fad98e479ff391faa876
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 2, 2026.

Transparency log

Release files / mlx_learn-0.1.1-cp313-cp313-macosx_11_0_arm64.whl

Download URL mlx_learn-0.1.1-cp313-cp313-macosx_11_0_arm64.whl
Size 398.4 kB
Tags CPython 3.13 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
dfa2c9f6804ed73b1a7e0a3181f23e042dd2632e8d2ac083366ab5623fdd29d8
BLAKE2b-256 checksum
How to use checksums
95f5c7d3594709b8a0f371bfe349125266d8a39db6ef504b6f80ced249a78e89
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 2, 2026.

Transparency log

Release files / mlx_learn-0.1.1-cp312-cp312-macosx_11_0_arm64.whl

Download URL mlx_learn-0.1.1-cp312-cp312-macosx_11_0_arm64.whl
Size 398.4 kB
Tags CPython 3.12 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
8475263ea7843996a5f43006cb52adcb424eb095ac4747c09ba0489db82ffb55
BLAKE2b-256 checksum
How to use checksums
8060e08526aafe55c02007ed9f135870152ea7e947e6f291eb28995ff7a3c772
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 2, 2026.

Transparency log

Release files / mlx_learn-0.1.1-cp311-cp311-macosx_11_0_arm64.whl

Download URL mlx_learn-0.1.1-cp311-cp311-macosx_11_0_arm64.whl
Size 398.4 kB
Tags CPython 3.11 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
870eb05bc4b4a149a27a385ce31b53e2b0a07fe3c7b50f2933db9c8a3ac01a6b
BLAKE2b-256 checksum
How to use checksums
a0748287d1f8314edf6e0ba0926f0824d0c7ffd0165045fae59efff0e4ea7b6d
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 2, 2026.

Transparency log

Release files / mlx_learn-0.1.1-cp310-cp310-macosx_11_0_arm64.whl

Download URL mlx_learn-0.1.1-cp310-cp310-macosx_11_0_arm64.whl
Size 398.4 kB
Tags CPython 3.10 macOS 11.0+ ARM64
SHA-256 checksum
How to use checksums
0102773c1e1510982aa78c6ff970e39855dbf0e0a252853f4df946bbb2bd785a
BLAKE2b-256 checksum
How to use checksums
0fe5b19a4e2b35ffc511fd287ba6d46548c142eafa33b7fe6786014cef62c4e2
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 2, 2026.

Transparency log

Security for mlx-learn 0.1.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 5 files in this release have been uploaded with provenance metadata.

Select from 5 files

Attestation for mlx_learn-0.1.1.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Nov 2, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page