GitHub user rok edited a comment on the discussion: A new home for pyarrow-stubs?
> how do we maintain this? A way I can see to maintain annotations is to have CI validate them with every Arrow PR. That would mean any time Python API is changed it would require author of the change to update the annotations to pass the CI checks. This is arguably the best time to do so as the person making the change is supposedly well informed about the types being passed. It is an added cost for maintenance, but not a great one as our changes are quite atomic and require little annotation changes (I have not rigorously checked this). NumPy seems to be doing this for a while, see: https://github.com/numpy/numpy/pull/28073, https://github.com/numpy/numpy-stubs/issues/79, https://github.com/numpy/numpy/pull/16515. They also seem to use a issue tracker tag [TYP](https://github.com/numpy/numpy/pulls?q=is%3Apr+is%3Aopen+TYP%3A) that has a non-negligible amount of PRs. Alternatively we can keep stubs in a separate repo, but as [pyarrow-stubs experience](https://github.com/zen-xu/pyarrow-stubs/issues/186#issuecomment-2719555323) shows it's more than a one-man-part-time workload to stay in sync with the project. Further, external stubs then target releases which makes annotations less useful at development time. If we were to target main Arrow branch (instead of release only) but in a separate repo we'd likely double the amount of PRs (one PR for a change, one PR for type annotation change. GitHub link: https://github.com/apache/arrow/discussions/45919#discussioncomment-14245807 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
