lib-tusharelisted

# tushare The cheapest route to real point-in-time A-share fundamentals — and the owner of the most dangerous adjustment implementation in the Chinese ecosystem, which is **worse than ordinary qfq**. | | | |---|---| | pip / import | `tushare` / `import tushare as ts` | | Version | 1.4.29 (2026-03-25) · 229 releases | | Licence | BSD-3-Clause (GitHub SPDX; PyPI classifier says "BSD License") | | Python | `requires_python` is **null** — declares nothing; pure-python wheel + sdist | | Status | The public repo is **not** the source of truth: idle since 2024-03-13, PyPI shipped 2026-03 | Access is token + 积分 (points). There are **no client-side permission checks** at all. ## The trap that costs you money **`pro_bar(adj="qfq")` is anchored to YOUR `end_date`, not to today.** Verified in `tushare/pro/data_pro.py`: ```python if adj == 'hfq': data[col] = data[col] * data['adj_factor'] if adj == 'qfq': data[col] = data[col] * data['adj_factor'] / float(fcts['adj_factor'][0]) ``` `fcts` arrives **newest-first**, so `[0]` is the factor on **the last date of your query window**. The same bar returns different prices depending on what `end_date` you asked for. Two overlapping queries disagree; concatenating them produces a series with a silent discontinuity at the seam. Ordinary qfq is merely non-reproducible over time — this is non-reproducible over *query parameters*. In the same function, `pre_close = close.shift(-1)` is correct **only because rows arrive descending**. Sort the