feat: migrate to polars + uv (v2.0.0) — RFC / Discussion

[buzzvolt]

RFC: pandas → Polars migration + uv tooling (v2.0.0)

This is an invitation to discuss, not a request to merge immediately.

The full rationale, every breaking change, and side-by-side code comparisons
are documented in docs/migration-v2-polars.md
(rendered below on GitHub).

Why open this PR?

The two most consistent pain points in yfinance's history have been:

1. The MultiIndex column output of download() — there is a dedicated
   doc page for it that simply points to a Stack Overflow answer. The
   community's own workaround (df.stack(level=1).reset_index()) produces
   exactly the long-form shape this PR returns natively.

2. pandas as a hard dependency — polars is faster, has an immutable
   DataFrame model that eliminates a whole class of mutation bugs present
   in the current codebase (including df._consolidate() being called in
   production), and requires no index concept (dates are explicit columns).

PR #2782 focuses on

Area	Change
Packaging	setup.py → pyproject.toml + uv
CI	Re-enables the disabled pytest.yml; all workflows use uv run
download()	Returns long-form pl.DataFrame with "Ticker" column instead of MultiIndex
history()	Returns pl.DataFrame; as_pandas=True bridge for backward compat
All scrapers	Fully migrated to polars; no pandas import in normal code path
Price repair	Pragmatic pandas bridge retained internally; repair still works
Tests	42/46 pass; 4 failures are pre-existing (permissions, live data counts)
Docs	1446-line migration guide in docs/migration-v2-polars.md

What stays the same

• All function signatures (parameters, defaults, behaviour)
• actions=True default — Dividends/Stock Splits columns present as before
• repair=True — works when pandas[pandas] extra installed
• as_pandas=True on history() — returns exact v1 DataFrame shape

Questions for the maintainer / community

• Is a long-form download() output something the community would embrace?
• Should the pandas compat bridge be a first-class supported path or temporary?
• Would you prefer the repair engine be fully native polars before merging?
• Any concerns about dropping Python 3.6–3.9 support (now >=3.10)?

Happy to split this into smaller incremental PRs (e.g. just the uv/packaging
change, or just the download() shape change) if that makes review easier.

[buzzvolt]

cc @dokson @edoaltamura @ValueRaider

[dokson]

#2808 for ref 😉

[ValueRaider]

obviously for speed

Are the yfinance dataframes big enough for this to be measurable, compared to Python interpreter and network? Have you benchmarked actual yfinance operations, not micro-benchmarks like groupby?

[buzzvolt]

docs/migration-v2-polars.md
Section 14 and Section 15 can help address some of the questions/concerns. I would definitely like someone to give the PR or the branch, a try in their sandbox environment and see/compare the results on their own hardware/platform for themselves.

[ValueRaider]

Sections 14 15 are the micro-benchmarks.