mirror of
https://github.com/astral-sh/ruff.git
synced 2025-08-22 11:25:26 +00:00
5f6b0ded21
Most of the work here was doing some light refactoring to facilitate sensible testing. That is, we don't want to list every builtin included in most tests, so we add some structure to the completion type returned. Tests can now filter based on whether a completion is a builtin or not. Otherwise, builtins are found using the existing infrastructure for `object.attr` completions (where we hard-code the module name `builtins`). I did consider changing the sort order based on whether a completion suggestion was a builtin or not. In particular, it seemed like it might be a good idea to sort builtins after other scope based completions, but before the dunder and sunder attributes. Namely, it seems likely that there is an inverse correlation between the size of a scope and the likelihood of an item in that scope being used at any given point. So it *might* be a good idea to prioritize the likelier candidates in the completions returned. Additionally, the number of items introduced by adding builtins is quite large. So I wondered whether mixing them in with everything else would become too noisy. However, it's not totally clear to me that this is the right thing to do. Right now, I feel like there is a very obvious lexicographic ordering that makes "finding" the right suggestion to activate potentially easier than if the ranking mechanism is less clear. (Technically, the dunder and sunder attributes are not sorted lexicographically, but I'd put forward that most folks don't have an intuitive understanding of where `_` ranks lexicographically with respect to "regular" letters. Moreover, since dunder and sunder attributes are all grouped together, I think the ordering here ends up being very obvious after even a quick glance.) |
||
|---|---|---|
| .. | ||
| resources | ||
| src | ||
| tests | ||
| build.rs | ||
| Cargo.toml | ||
| mdtest.py | ||
| mdtest.py.lock | ||