PR Check Results

Ecosystem

ℹ️ ecosystem check detected linter changes. (+10 -0 violations, +0 -0 fixes in 41 projects)

ruff check --no-cache --exit-zero

+ rotkehlchen/assets/resolver.py:127:9: PLC0415 `import` should be at the top-level of a file
+ rotkehlchen/assets/resolver.py:128:9: PLC0415 `import` should be at the top-level of a file
+ rotkehlchen/assets/resolver.py:158:9: PLC0415 `import` should be at the top-level of a file
+ rotkehlchen/assets/resolver.py:159:9: PLC0415 `import` should be at the top-level of a file
+ rotkehlchen/assets/resolver.py:70:9: PLC0415 `import` should be at the top-level of a file
+ rotkehlchen/assets/resolver.py:71:9: PLC0415 `import` should be at the top-level of a file
+ rotkehlchen/assets/resolver.py:96:9: PLC0415 `import` should be at the top-level of a file
+ rotkehlchen/assets/resolver.py:97:9: PLC0415 `import` should be at the top-level of a file
+ rotkehlchen/tests/conftest.py:133:9: PLC0415 `import` should be at the top-level of a file
+ tools/pyinstaller_hooks/pre_find_module_path/hook-distutils.py:40:5: PLC0415 `import` should be at the top-level of a file

@charliermarsh I've gone with your suggestion of just checking the semantic scope kind. I had misinterpreted one of the tests from pylint and it does look like they considered nested conditionals to be at the top-level (and that's why pylint needs no special handling for type-checking).

I've also updated the documentation for this check as I don't think PEP8 completely offers a rationale for this rule. The pylint PR for this rule also doesn't provide a lot of explanation, so I've done my best to offer a more complete rationale for this check, but I'd welcome suggestions.

For the record, this is why ChatGPT thinks we should place our imports at the top-level of a module:

why should I place my imports at the top-level of a module in python?
ChatGPT
In Python, it is generally recommended to place your imports at the top-level of a module. Here are some reasons why this is a good practice:

Readability: Placing imports at the top of your module makes it easier for other developers (including yourself) to understand and navigate your code. When imports are at the top, it provides a clear and concise view of the dependencies required by your module.

Avoiding Confusion: Placing imports at the top-level helps prevent potential conflicts and confusion. It allows you to easily see which external modules or libraries your code relies on, reducing the chances of accidentally redefining or overriding names used in other parts of your code.

Consistency: Placing imports at the top-level is a widely followed convention in the Python community. By adhering to this convention, you make your code more familiar and consistent with other Python projects, which can facilitate collaboration and code maintenance.

Dependency Analysis: When imports are located at the top, it becomes easier to analyze the dependencies of a module. Tools like static analyzers or linters can quickly scan the imports and identify any potential issues or unused imports.

Performance: Import statements at the top-level are executed only once when the module is first imported, and subsequent imports of the same module do not execute those statements again. Placing imports within functions or conditional blocks may lead to repeated imports, which can impact performance.

However, it's worth noting that there are a few exceptions or alternative approaches to consider. For instance, if an import is only needed within a specific function or block of code, it can be placed there to improve the performance of the module as a whole. Additionally, there may be cases where conditional imports are required based on runtime conditions. But as a general guideline, placing imports at the top-level is considered a good practice in Python.

The autofix for this could be #1251