Sets vs lists in Home Assistant

[rlippmann]

Hi,

Looking through the codebase, it seems like there are a couple of places where using sets would be more efficient/clearer than where existing lists are used.

In particular:
modes/supported features on certain entity types
groups
action call targets

and there are probably more that I haven't come across.

I was wondering if there was any particular architectural/design decision that caused lists to be used instead of sets in those cases? And, if changing them would cause more harm in terms of breaking existing integrations than good.

[MartinHjelmare]

There's no general design pattern that says we should avoid sets. We should use the object type that is most appropriate for the case at hand.

If you're wondering about a particular case, it's better to ask a question on Discord or open an issue in the appropriate issue tracker, or open a PR to change it if you think that is appropriate.

[rlippmann]

Looking at entity presets, which are currently lists, I think the correct and more performant way to implement them is via sets.

Unfortunately, it looks like this will require a lot of minor code changes throughout the codebase. And I'm not sure the effort is warranted unless the maintainers decree this as a requirement. And since it touches a large number of integrations, this might be a nightmare to get reviews from all the code owners.

[mik-laj]

In most parts of Home Assistant, raw performance is not the limiting factor. A typical HA installation serves a single household, spends most of its lifetime idle, and wakes up only when something happens. Because of that, the real cost in this ecosystem is maintenance, not squeezing out micro-optimizations.

When we design a new feature, it absolutely makes sense to consider which data type best represents the semantics. But once a pattern is already established and widely used across the codebase, changing it retroactively rarely provides meaningful benefit. Rewriting existing lists into sets across multiple integrations introduces review overhead, testing overhead, merge conflicts, and a non-zero chance of regressions, with almost no practical gain for end users.

So unless a specific part of the code suffers from real issues that a set would clearly solve, sticking with the current structure is usually the more pragmatic approach.

[rlippmann]

Yeah, that was pretty much the conclusion I had reached.

Should they be sets? Probably. Would it be more efficient? Yes, but not very much. Is it worth the effort to change it? Definitely not.