[ty] Add builtins to completions derived from scope

[BurntSushi]

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.)

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[codspeed-hq]

CodSpeed WallTime Performance Report

Merging #18982 will not alter performance

_{Comparing ag/completion-builtins (67134b1) with main (a3c79d8)}

Summary

✅ 8 untouched benchmarks

[AlexWaygood]

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.)

I think I'd be in favour of making this change so that they're sorted below other candidates... in the playground here, it was slightly annoying that Protocol was sorted below PendingDeprecationWarning in the list of autocompletions. It seems obvious that it's the most likely candidate for what I want, given that I just imported it! 😆

[dhruvmanila]

Looks great!

[BurntSushi]

@AlexWaygood I think if we were going to go that route, we'd need to be more thoughtful about our ranking. I'm pretty concerned about having an unpredictable order and that making it difficult for folks to scan the list quickly to find what they're looking for.

[AlexWaygood]

I definitely get that concern. I think having the likeliest attribute be as close to the top of the list as possible is quite high-value, but I definitely agree that having a consistent and predictable behaviour is also high-value. I'm fine with parking this for now and coming back to it later!