With astral-sh/ruff#22581, ty started filtering out completions for redundant re-exports deeper in a package's hierarchy. For example, instead of suggesting all of pandas.read_csv, pandas.io.api.read_csv, pandas.io.parsers.read_csv and pandas.io.parsers.readers.read_csv, ty will only suggest pandas.read_csv.

However, if you're working on Pandas, you might reasonably want to see all available re-exports. Or perhaps even more precisely, see the "closest" re-export. The latter is perhaps ideal, but requires defining a notion of "closesness" that is more refined than "top-most." We could start by implementing the former and leave the latter for future work.

That is, it should be pretty straight-forward to avoid doing any kind of dropping of re-exports when you're within first party code (just look at the search path of the containing Module). So that if you're working on pandas, you'll see all 4 re-exports. But if you're depending on pandas, you only get the top-level one.

The one thorny part of this though is testing. We don't have a great story right now for testing how we handle Python files coming from different search paths in a granular way. We could add support to it in our CursorTest infrastructure. An alternative is to write an end-to-end integration test.