repo
One command was observed. Code it does not exercise is not observed; "no difference" means the normalized output and exit status matched, not that the fix is correct.
17 enabled rule(s) already have a finding in the bank (5 more known-risk rules of ruff are not enabled here)
FURB129fix changes program behavior
- files changed
- 1: python/toolbox/logs.py
- reduced to
- 1 of 1 hunk(s) in python/toolbox/logs.py, 1 run(s); the patch was applied with git apply and reproduced the same difference
- sites reported
- 1 → 0 in 1 linted file(s)
Change (reduced)
--- a/python/toolbox/logs.py +++ b/python/toolbox/logs.py @@ -4,7 +4,7 @@ def has_duplicate(path): """True when any line occurs more than once. Each line is compared against a fresh pass over the file.""" with open(path) as fp: - for line in fp.readlines(): + for line in fp: fp.seek(0) if sum(1 for other in fp if other == line) > 1: return True
Observed
exit 0 → 1 stderr last line before: OK stderr last line after: FAILED (failures=1)
Output after tail
======================================================================
FAIL: test_duplicate_after_first_line (tests.test_logs.LogTests.test_duplicate_after_first_line)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/w/python/tests/test_logs.py", line 13, in test_duplicate_after_first_line
self.assertTrue(has_duplicate(p))
AssertionError: False is not true
----------------------------------------------------------------------
Ran 10 tests in 0.007s
FAILED (failures=1)Judge Nemotron 3 Ultra, advisory
The fix replaces `fp.readlines()` with `fp`, changing the iteration from a pre-read list of lines to a live iterator over the file object. The program relies on `fp.seek(0)` inside the loop to restart reading from the beginning for each outer line, which works with `readlines()` because the outer iteration is over an in-memory list, but fails when iterating directly over `fp` because the file position is shared and the outer loop exhausts the iterator after the first inner pass.
Upstream
Files
PLR1733fix changes program behavior
- files changed
- 1: python/toolbox/registry.py
- reduced to
- 1 of 1 hunk(s) in python/toolbox/registry.py, 1 run(s); the patch was applied with git apply and reproduced the same difference
- sites reported
- 1 → 0 in 1 linted file(s)
Change (reduced)
--- a/python/toolbox/registry.py +++ b/python/toolbox/registry.py @@ -27,5 +27,5 @@ out = {} for key, value in table.items(): for key in value: - out[key] = table[key] if key in table else None + out[key] = value if key in table else None return out
Observed
exit 0 → 1 stderr last line before: OK stderr last line after: FAILED (failures=1)
Output after tail
File "/w/python/tests/test_registry.py", line 15, in test_resolve_listed_names
self.assertEqual(resolve(table), {"b": [], "c": None})
AssertionError: {'b': ['b', 'c'], 'c': None} != {'b': [], 'c': None}
- {'b': ['b', 'c'], 'c': None}
? --------
+ {'b': [], 'c': None}
----------------------------------------------------------------------
Ran 10 tests in 0.007s
FAILED (failures=1)Judge Nemotron 3 Ultra, advisory
The fix incorrectly assumes the inner loop variable 'key' iterates over the outer dict's keys, but it actually iterates over 'value' (which could be a list or other iterable). Replacing 'table[key]' with 'value' substitutes the entire iterable for the specific looked-up element, changing the program's logic and causing a test failure.
Explanation Nemotron 3 Super, model draft
The original inner loop uses `key` as both the outer variable from `table.items()` and the iterator over `value`, shadowing it; thus `table[key]` refers to the current row’s dictionary entry under that iterated element. After rewriting, `value` replaces `table[key]`, but `value` is the entire list/dict of keys being iterated—so each assignment stores the whole collection instead of individual elements, altering output structure and causing test failures.
Upstream
Files
FURB103fix changes program behavior
- files changed
- 1: python/toolbox/config.py
- reduced to
- 1 of 1 hunk(s) in python/toolbox/config.py, 1 run(s); the patch was applied with git apply and reproduced the same difference
- sites reported
- 2 → 0 in 1 linted file(s)
Change (reduced)
--- a/python/toolbox/config.py +++ b/python/toolbox/config.py @@ -1,13 +1,12 @@ """Write configuration files.""" +import pathlib def save(path, text, enabled): """Write `text` to `path` only when `enabled`; the file is created (and truncated) either way.""" - with open(path, "w") as f: - enabled and f.write(text) + pathlib.Path(path).write_text(text) def save_count(path, text): """Write `text` and print the number of characters written.""" - with open(path, "w") as f: - print(f.write(text)) + pathlib.Path(path).write_text(text)
Observed
exit 0 → 1 stderr last line before: OK stderr last line after: FAILED (failures=2)
Output after tail
----------------------------------------------------------------------
Traceback (most recent call last):
File "/w/python/tests/test_config.py", line 15, in test_save_disabled_writes_nothing
self.assertEqual(p.read_text(), "")
AssertionError: 'debug=1\n' != ''
- debug=1
----------------------------------------------------------------------
Ran 10 tests in 0.007s
FAILED (failures=2)Judge Nemotron 3 Ultra, advisory
The fix replaces a conditional write (`enabled and f.write(text)`) with an unconditional `Path.write_text(text)`, changing the behavior when `enabled` is false: the original creates/truncates the file but writes nothing, while the fix always writes the text. The documentation presents the rewrite as equivalent for writing a single string, but does not account for guarded writes.
Explanation Nemotron 3 Super, model draft
The replacement removes conditional execution based on `enabled`, always writing `text`. It also discards the return value of `f.write()` in both functions—used implicitly for truthiness in `save` and explicitly printed in `save_count`—so side effects like printing character count or respecting the `enabled` flag are lost, altering behavior.
Upstream
Files
RUF019fix changes program behavior
- files changed
- 1: python/toolbox/registry.py
- reduced to
- 1 of 1 hunk(s) in python/toolbox/registry.py, 1 run(s); the patch was applied with git apply and reproduced the same difference
- sites reported
- 1 → 0 in 1 linted file(s)
Change (reduced)
--- a/python/toolbox/registry.py +++ b/python/toolbox/registry.py @@ -17,7 +17,7 @@ def lookup(reg, key): """The registered value when present and truthy, else None.""" - if key in reg and reg[key]: + if reg.get(key): return reg[key] return None
Observed
exit 0 → 1 stderr last line before: OK stderr last line after: FAILED (errors=1)
Output after tail
File "/w/python/tests/test_registry.py", line 10, in test_lookup_registered
self.assertEqual(lookup(reg, "db"), "postgres")
^^^^^^^^^^^^^^^^^
File "/w/python/toolbox/registry.py", line 20, in lookup
if reg.get(key):
^^^^^^^
AttributeError: 'Registry' object has no attribute 'get'
----------------------------------------------------------------------
Ran 10 tests in 0.007s
FAILED (errors=1)Judge Nemotron 3 Ultra, advisory
The fix replaces `key in reg and reg[key]` with `reg.get(key)`, which changes behavior when the key exists but its value is falsy (e.g., 0, False, empty string). The original code returns None for falsy values, while the fixed code returns the falsy value itself, causing the function to return a falsy value instead of None and breaking the documented contract.
Explanation Nemotron 3 Super, model draft
The original condition checks both that `key` exists in `reg` (`key in reg`) and that its associated value is truthy (`reg[key]`). The rewritten version uses only `if reg.get(key):`, which returns `None` for missing keys or falsy values like `False`, `0`, or empty containers—causing it to skip returning those values even when they exist in the dictionary. Thus, legitimate entries with falsy but defined values now incorrectly yield `None`, changing behavior where such cases should have returned the stored value. This violates the function’s documented intent of returning the registered value when present and truthy—not merely when get() yields a truthy result.
Upstream
Files
Applied without a difference
4 rule(s) changed 1 file(s) with no difference under the command, applied together. accepted.patch applies with git apply -p1. UP004 UP015 F541 I001