The expected metric values in test_default_metric_binary and test_default_metric_binary_custom_loss are identical across every assertion (e.g., baseline_gini == approx(0.114333), enriched_gini == approx(0.032250), etc.), which undermines the value of the custom loss test. If test_default_metric_binary_custom_loss was designed to verify that a custom loss function affects metric computation, the two tests should produce different Gini/uplift values — otherwise the test only confirms the code runs without actually exercising the custom loss path meaningfully.

The CI change in .circleci/config.yml — creating a venv with python3.10 and activating it before calling tox — is an indirect way to pin the Python version. Since tox manages its own environments, the venv activation only affects which Python tox itself is invoked by. A cleaner and more explicit approach would be python3.10 -m tox directly, or specifying requires = python >= 3.10 in tox.ini, which makes the version constraint visible in the project config rather than buried in CI steps.