A004 Preview Mode ExceptionGroup import in pre-3.11

[CoolCat467]

Getting A004 Import BaseExceptionGroup is shadowing a Python builtin and ExceptionGroup errors raised in this case:

if sys.version_info < (3, 11):
    from exceptiongroup import BaseExceptionGroup, ExceptionGroup

I would argue that this should not be the case. BaseExceptionGroup and ExceptionGroup do not exist in python versions prior to 3.11, and using the exceptiongroup package is commonly used for backwards compatibility.

Using ruff preview mode v0.6.1

[MichaReiser]

This makes sense to me, but we should only allow the use of BaseExceptionGroup and ExceptionGroup when inside a sys.version_info < (3.11) branch. I'm not sure if we have the necessary infrastructure today. wdyt @AlexWaygood ?

[AlexWaygood]

I'm quite hesistant to add the infrastructure to Ruff to support detecting which sys.version_info branch we're in. Generalised sys.version_info parsing would be tricky (though we'll have to implement it for red-knot to comply with PEP 484), and I'm not sure it's actually needed in this case. For this case, I think we could fix the issue by making the is_python_builtin() function smarter:

• The rule calls shadows_builtin() here.
• shadows_builtin() calls is_python_builtin() here
• is_python_builtin() is defined here. Unlike other similar functions in the ruff_python_stdlib crate, it assumes that all Python builtins have always been Python builtins; it doesn't take account of the fact that some builtins were added in newer Python versions. If we added a minor_version parameter, similar to ruff_python_stdlib::sys::is_builtin_module or ruff_python_stdlib::sys::is_known_standard_library, then we could take account of the --target-version the user has provided when deciding whether something is a Python builtin or not. Since @CoolCat467 clearly supports running Python <3.11 on their code, they'll probably be running Ruff with --target-version py310 or lower.

[CoolCat467]

I think that using --target-version is a good solution