mirror of
https://github.com/astral-sh/ruff.git
synced 2025-10-02 22:55:08 +00:00
e2a30b71f4
This reverts https://github.com/astral-sh/ruff/pull/13799, and restores the previous behavior, which I think was the most pragmatic and useful version of the divide-by-zero error, if we will emit it at all. In general, a type checker _does_ emit diagnostics when it can detect something that will definitely be a problem for some inhabitants of a type, but not others. For example, `x.foo` if `x` is typed as `object` is a type error, even though some inhabitants of the type `object` will have a `foo` attribute! The correct fix is to make your type annotations more precise, so that `x` is assigned a type which definitely has the `foo` attribute. If we will emit it divide-by-zero errors, it should follow the same logic. Dividing an inhabitant of the type `int` by zero may not emit an error, if the inhabitant is an instance of a subclass of `builtins.int` that overrides division. But it may emit an error (more likely it will). If you don't want the diagnostic, you can clarify your type annotations to require an instance of your safe subclass. Because the Python type system doesn't have the ability to explicitly reflect the fact that divide-by-zero is an error in type annotations (e.g. for `int.__truediv__`), or conversely to declare a type as safe from divide-by-zero, or include a "nonzero integer" type which it is always safe to divide by, the analogy doesn't fully apply. You can't explicitly mark your subclass of `int` as safe from divide-by-zero, we just semi-arbitrarily choose to silence the diagnostic for subclasses, to avoid false positives. Also, if we fully followed the above logic, we'd have to error on every `int / int` because the RHS `int` might be zero! But this would likely cause too many false positives, because of the lack of a "nonzero integer" type. So this is just a pragmatic choice to emit the diagnostic when it is very likely to be an error. It's unclear how useful this diagnostic is in practice, but this version of it is at least very unlikely to cause harm. |
||
|---|---|---|
| .. | ||
| red_knot | ||
| red_knot_python_semantic | ||
| red_knot_server | ||
| red_knot_test | ||
| red_knot_vendored | ||
| red_knot_wasm | ||
| red_knot_workspace | ||
| ruff | ||
| ruff_benchmark | ||
| ruff_cache | ||
| ruff_db | ||
| ruff_dev | ||
| ruff_diagnostics | ||
| ruff_formatter | ||
| ruff_graph | ||
| ruff_index | ||
| ruff_linter | ||
| ruff_macros | ||
| ruff_notebook | ||
| ruff_python_ast | ||
| ruff_python_ast_integration_tests | ||
| ruff_python_codegen | ||
| ruff_python_formatter | ||
| ruff_python_index | ||
| ruff_python_literal | ||
| ruff_python_parser | ||
| ruff_python_resolver | ||
| ruff_python_semantic | ||
| ruff_python_stdlib | ||
| ruff_python_trivia | ||
| ruff_python_trivia_integration_tests | ||
| ruff_server | ||
| ruff_source_file | ||
| ruff_text_size | ||
| ruff_wasm | ||
| ruff_workspace | ||