`humanize_list` accepts any value that can be coerced to a string for the last list item
Metadata
Current evaluation
humanize_list silently stringifies a non-string final item (f-string) instead of raising TypeError. Reproduced on current main; maintainer deferred it to the emitter oxidation (#411) and the desired direction (reject vs coerce) is still unanswered.
Suggested action: keep open
Reason: lengau acknowledged "this is a real bug" but explicitly declined to triage it: "I'm not marking it as triaged since it's naturally fixed with the oxidization of this function." The bug is still live at HEAD — craft_cli/utils.py returns `f"{values[0]} {conjunction} {values[1]}"` for two-item lists (and `values[0]` raw for one item), so non-strings pass through, while 3+ items raise TypeError via `', '.join(head)`. The maintainer deliberately left it open pending craft-cli#411, so it must not be closed; hericlibong's 138-days-old question about the intended direction (raise TypeError vs coerce everything) is still unanswered, which caps actionability and confidence.
Evaluated by: mr-cal-bot
Issue body
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
18
Quick Win:
8
Complexity:
25
Confidence:
74
Actionability:
60
|
keep open | humanize_list silently stringifies a non-string final item (f-string) instead of raising TypeError. Reproduced on current main; maintainer deferred it to the emitter oxidation (#411) and the desired direction (reject vs coerce) is still unanswered. | |
| qwen/qwen3.6-35b-a3b |
Impact:
30
Quick Win:
17
Complexity:
20
Confidence:
80
Actionability:
70
|
keep open | humanize_list accepts non-string values without raising TypeError, with inconsistent behavior depending on item position | |
| qwen/qwen3.8-27b |
Impact:
15
Quick Win:
11
Staleness:
38
Complexity:
28
Confidence:
72
Support Request:
5
|
keep open | humanize_list silently coerces non-string items instead of raising TypeError, inconsistently by position. Maintainer acknowledged it as a real bug but deferred to a future Rust oxidization; a contributor reproduced it on main and awaits direction on intended behavior. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
45
Complexity:
15
Confidence:
85
Support Request:
0
|
needs triage | humanize_list accepts non-string items without raising TypeError, showing inconsistent behavior based on item position. Currently awaiting maintainer clarification on whether to patch now or defer to the Rust migration. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
50
Complexity:
15
Confidence:
85
Support Request:
0
|
keep open | humanize_list coerces non-string items to strings instead of raising TypeError. Currently under discussion regarding intended coercion behavior ahead of an ongoing Rust rewrite. |
Update history
No update history recorded yet.
Related work
-
Blocked By:
canonical/craft-cli#411
(confidence 62%)
Maintainer says the issue is "naturally fixed with the oxidization of this function"; hericlibong read the Rust version as coercing via item.to_string(), which may resolve it by accepting all values rather than rejecting them. The pinned tree still contains the pure-Python utils.py and setuptools build backend, so the resolution path isn't verifiable here.
-
Related To:
canonical/craft-cli#425
(confidence 55%)
Commit c7a1d2b "fix(utils): correct humanize_list for two-item lists" touched the same function for a separate formatting bug (serial comma) and added tests/unit/test_utils.py, but did not add any non-string/type-strictness coverage.
Related issues
No related issues found above the similarity threshold.