rok commented on issue #32609: URL: https://github.com/apache/arrow/issues/32609#issuecomment-6092043422
@jorisvandenbossche > Seeing [rok#62](https://github.com/rok/arrow/pull/62), some general questions: > > * do we want to put the stubs in a separate directory? (`python/pyarrow-stubs`) Or rather alongside the source? I would slightly prefer `python/pyarrow-stubs` as we as we already have some [machinery for this in place](https://github.com/apache/arrow/blob/5ef3c5200359bc8e2375daf5f989369b0c8c089b/python/CMakeLists.txt#L1060-L1067). I find the .pyi files in the regular tree distracting for working on stabs and editors allow ctrl + click navigation through from stubs to source, so this is not a huge issue. I'd suggest we keep them separate for duration of the work and if we so decide move them into the "regular python tree" when we're done. > * for pure python files, do we want to use a stub file, or rather inline the annotations? (except for compute.py) From my experience working on the entire pyarrow-stubs import PRs, I found stubs separate from the code much more readable. The absence of logic makes it really easy to parse and batch edit them. I would poropose that if we do move them inline we do it after we've created them as stubs first. I believe we also discussed this here or somewhere else. > * do we want to type internal python functions? (I would, but not if those are in separate stubs, at that point we should IMO keep it to public APIs) I would too. Not sure what you mean by separate stubs. > (personally, I am in favor of putting it as close to the actual source as possible, which means inline when possible (most python files) and the stub files alongside the code; but I don't know if this was discussed before or if there are specific reasons for the current setup) This was probably discussed before here or on the [discussion](https://github.com/apache/arrow/discussions/45919). As proposed above - moving annotations inline should be automatable. Let's open an issue for that specifically and decide on it after we have well type annotated stubs. @sakgoyal > along side source is better imho. I think adding adding them inline is a good idea for pure python. it's less messy for everyone and easier to find things compared to having things spread out. It would also ensure things stay synced up. See my reply above. > The bare minimum would be to have fully strict types for everything public facing. Internal would be good too of course, but not required for the initial stage. Agreed. > Probably a big ask, but making sure the types are supported across all major type checkers would also be greatly appreciated (mypy, pyright/basedpyright, ruff/ty, pyrefly) Existing PRs porting pyarrow-stubs passed mypy/pyright/ty checks. I would strive for somesort of reasonable set that would keep maintenance reasonable. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
