Ruff rule to standardise import x.y.z as alias and from x.y import z as alias

[epenet]

Hi,

The current Home Assistant code base has a mix of import x.y.z as alias and from x.y import z as alias

This leads to funny aesthetics, for example:

from homeassistant.helpers import device_registry as dr
import homeassistant.helpers.issue_registry as ir

or

from homeassistant.const import CONF_DEVICE_CLASS, CONF_NAME
from homeassistant.core import HomeAssistant
import homeassistant.helpers.config_validation as cv
from homeassistant.helpers.entity_platform import AddEntitiesCallback
from homeassistant.helpers.typing import ConfigType, DiscoveryInfoType

It would be nice to have a rule to be able to enforce from x.y import z as alias, which will also unlock the grouping

from homeassistant.helpers import device_registry as dr, issue_registry as ir

or

from homeassistant.const import CONF_DEVICE_CLASS, CONF_NAME
from homeassistant.core import HomeAssistant
from homeassistant.helpers import config_validation as cv
from homeassistant.helpers.entity_platform import AddEntitiesCallback
from homeassistant.helpers.typing import ConfigType, DiscoveryInfoType

Current isort configuration:

[tool.ruff.lint.isort]
force-sort-within-sections = true
known-first-party = [
    "homeassistant",
]
combine-as-imports = true
split-on-trailing-comma = false

[epenet]

Note: these are linked PRs on HA code base

• Prefer from...import...as over import...as in core tests home-assistant/core#136146 (merged - fixes some initial violations)
• Enforce from...import...as via pylint plugin home-assistant/core#136156 (draft of a pylint plugin which would be better replaced with a ruff rule)
• Replace import...as with from...import...as home-assistant/core#136162 (pending - would fix all violations for homeassistant namespace)

[MichaReiser]

I think that overall makes sense but I'm not sure if it should go into isort or any of the other import-related linters.

[AlexWaygood]

Is this a duplicate of #14070?

[dhruvmanila]

I think #14070 is different than what's being asked here in that the linked issue is requesting to maintain consistency between import ... and from ... style imports i.e., strictly use one or the other (IIUC reading the issue description).

[MichaReiser]

requesting to maintain consistency between import ... and from ... style imports i.e., strictly use one or the other (IIUC reading the issue description

But isn't this the same as is requested in this issue 😆?

[dhruvmanila]

I think @epenet might be able to provide more context here. Is the request here strictly about converting a import x.y as z to from x import y as z or does the conversion from import x.y to from x import y is also applicable here.

While writing this, I realized that considering both might be more useful and thus this can be marked as duplicate of #14070

[epenet]

I was not aware of #14070, and it is definitely related.
However, I think that #14070 is too broad as not all imports are equivalent, and you cannot always migrate in both directions between mixed <=> option 1 <=> option 2.

I'll try to add a comment there but maybe keep this open a little while longer...