ruff G010: fix changes program behavior

Hypothesis Nemotron 3 Super predicted to fire fired 1×

string formatting edge cases: %, format, f-strings, repr vs str, nested quotes

Program

Output

(no stdout)
/w/prog.py:4: DeprecationWarning: The 'warn' method is deprecated, use 'warning' instead

(no stdout)
Hello Alice

Judge Nemotron 3 Ultra advisory intended-change · low

The rule rewrites the deprecated `logger.warn` call to `logger.warning`, which the documentation states is functionally equivalent. The observed difference is that the DeprecationWarning emitted by the old call disappears after the fix, which is exactly the semantic change the rule exists to make.

Explanation Nemotron 3 Super unverified

The original call to `logger.warn` produces a deprecation warning on standard error because the method is deprecated; this side effect is observable behavior. Replacing it with `logger.warning` eliminates that warning, altering the program’s stderr output while stdout remains unchanged. Since the fix changes what is printed to stderr, it does not preserve the original program’s semantics. A truly semantics-preserving transformation must maintain all observable effects, including warnings. Thus labeling the fix as safe is incorrect when deprecation warnings are considered part of the program’s behavior.

Reproduce

file

prog.py (the before program)

minimized program

r2-p003.py

evidence sheet

r2-p003.md

regression fixture

r2-p003.py the minimized program with a header stating the observed change, for the tool's test suite

python3 prog.py
ruff check --preview --isolated --select G010 --fix prog.py
python3 prog.py

Upstream search GitHub issues Tavily Nemotron 3 Super + Ultra

G010 fix · ruff G010 warn method deprecation · logging warn call replacement warning · deprecated warn to warning migration

• duplicate astral-sh/ruff/issues/12295 same rule G010 and same construct: rewriting deprecated `logger.warn` to `logger.warning`
• related astral-sh/ruff/issues/7248 same rule family (flake8-logging) but different specific rules and constructs
• related astral-sh/ruff/issues/2186 same rule G010 mentioned as alias but different defect class (aliasing vs autofix behavior)
• related astral-sh/ruff/issues/13673 same G rule family but different construct (loguru vs stdlib logging)
• related astral-sh/ruff/issues/17219 same rule G010 and logging context but different construct (G004 f-string vs G010 warn deprecation)
• related astral-sh/ruff/issues/15555 same G rule family (flake8-logging-format) and autofix context but different pattern/construct

Details

program

String formatting edge cases with % and f-strings

hazard

string formatting edge cases: %, format, f-strings, repr vs str, nested quotes

oracle

stderr before: /w/prog.py:4: DeprecationWarning: The 'warn' method is deprecated, use 'warning' instead stderr after: Hello Alice

run

2026-10-17T20-24-12-113Z-iye4-ruff-G010

--- orig.py	2026-10-17 16:24:36.413873903 -0400
+++ fixed.py	2026-10-17 16:24:36.668873256 -0400
@@ -2,6 +2,6 @@
 logger = logging.getLogger()
 logger.setLevel(logging.INFO)
 name = 'Alice'
-logger.warn('Hello %s' % name)
-logger.warn(f'Hello {name}')
-logger.warn('Hello {}'.format(name))
+logger.warning('Hello %s' % name)
+logger.warning(f'Hello {name}')
+logger.warning('Hello {}'.format(name))

# logging-warn (G010)

Derived from the **flake8-logging-format** linter.

Fix is always available.

## What it does
Checks for uses of `logging.warn` and `logging.Logger.warn`.

## Why is this bad?
`logging.warn` and `logging.Logger.warn` are deprecated in favor of
`logging.warning` and `logging.Logger.warning`, which are functionally
equivalent.

## Known problems

This rule detects uses of the `logging` module via a heuristic.
Specifically, it matches against:

- Uses of the `logging` module itself (e.g., `import logging; logging.info(...)`).
- Uses of `flask.current_app.logger` (e.g., `from flask import current_app; current_app.logger.info(...)`).
- Objects whose name starts with `log` or ends with `logger` or `logging`,
  when used in the same file in which they are defined (e.g., `logger = logging.getLogger(); logger.info(...)`).
- Imported objects marked as loggers via the [`lint.logger-objects`] setting, which can be
  used to enforce these rules against shared logger objects (e.g., `from module import logger; logger.info(...)`,
  when [`lint.logger-objects`] is set to `["module.logger"]`).

## Example
```python
import logging

logging.warn("Something happened")
```

Use instead:
```python
import logging

logging.warning("Something happened")
```

## Options
- `lint.logger-objects`

## References
- [Python documentation: `logging.warning`](https://docs.python.org/3/library/logging.html#logging.warning)
- [Python documentation: `logging.Logger.warning`](https://docs.python.org/3/library/logging.html#logging.Logger.warning)