Proposed change

Pylint 2.9 added a new optional extension: CodeStyle checker. Those checks don't necessarily provide performance improvements or catch errors, but instead are useful for code consistency and quality.

Currently, there are two checks:

1. consider-using-tuple: In-place defined lists in for loops and if clauses can almost always be replaced by tuples.

for var in [`some_name`, `some_other_name`]:
   ...

2. consider-using-namedtuple-or-dataclass: Emitted if dict values can be replaced by a NamedTuple or dataclass. Especially useful for sensor definitions. Currently they are mostly handled like the example from metoffice/sensor.py below: each sensor has a dict entry and the attributes are captured in a list or tuple. Later they are accessed via index lookup which is prone to errors, difficult to understand, and nearly impossible to type check. At least, the example has a comment explaining the individual fields but that isn't the norm.
   

   core/homeassistant/components/metoffice/sensor.py

   Lines 37 to 48 in 71a8ae3

   	# Sensor types are defined as:
   	# variable -> [0]title, [1]device_class, [2]units, [3]icon, [4]enabled_by_default
   	SENSOR_TYPES = {
   	"name": ["Station Name", None, None, "mdi:label-outline", False],
   	"weather": [
   	"Weather",
   	None,
   	None,
   	"mdi:weather-sunny", # but will adapt to current conditions
   	True,
   	],
   	"temperature": ["Temperature", DEVICE_CLASS_TEMPERATURE, TEMP_CELSIUS, None, True],

   
   In contrast, this is how it could look like:
   

   core/homeassistant/components/huawei_lte/sensor.py

   Lines 48 to 67 in 71a8ae3

   	class SensorMeta(NamedTuple):
   	"""Metadata for defining sensors."""
   	name: str | None = None
   	device_class: str | None = None
   	icon: str | Callable[[StateType], str] | None = None
   	unit: str | None = None
   	enabled_default: bool = False
   	include: re.Pattern[str] | None = None
   	exclude: re.Pattern[str] | None = None
   	formatter: Callable[[str], tuple[StateType, str | None]] | None = None
   	SENSOR_META: dict[str | tuple[str, str], SensorMeta] = {
   	KEY_DEVICE_INFORMATION: SensorMeta(
   	include=re.compile(r"^WanIP.*Address$", re.IGNORECASE)
   	),
   	(KEY_DEVICE_INFORMATION, "WanIPAddress"): SensorMeta(
   	name="WAN IP address", icon="mdi:ip", enabled_default=True
   	),

   
   As there are quite a lot of components that use lists, I had to disable the check for now. If the PR is accepted, I plan to open a tracking that enables the check. After that each component that uses the old style would need to be updated, preferable by the code-owner in a separate PR.

Links
http://pylint.pycqa.org/en/latest/whatsnew/2.9.html
http://pylint.pycqa.org/en/latest/technical_reference/extensions.html#pylint-extensions-code-style

--
/CC: @frenck

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.