Skip to content

Conversation

@danparizher
Copy link
Contributor

Summary

Fixes #19927

@github-actions
Copy link
Contributor

github-actions bot commented Aug 31, 2025

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

@dscorbett
Copy link

With this change, {**{}} is considered falsey; what about {**{**{}}}?

@danparizher
Copy link
Contributor Author

With this change, {**{}} is considered falsey; what about {**{**{}}}?

Good call, I had nested dict displays as truthy. I just pushed a change to have them checked recursively.

@ntBre ntBre added bug Something isn't working rule Implementing or modifying a lint rule labels Sep 9, 2025
DictItem {
key: None,
value: Expr::Name(..)
// If the dict consists only of double-starred items (e.g., {**x, **y}),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for diving deep here, but I think I'd kind of lean towards just considering any starred mapping to be of unknown truthiness (so just removing the Expr::Name requirement from matches!). I don't think nested, unpacked, empty dict literals are very common, so it seems like a nicer trade-off between implementation complexity and accuracy. That's also what we do for lists, sets, and tuples just above this. Expr::is_starred_expr for those elements is analogous to matches!(item, DictItem { key: None, ... }) for dicts.


# Check dict display with only double-starred expressions can be falsey.
Popen("true", shell={**{}})
Popen("true", shell={**{**{}}})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might also be nice to add a test case for a more common version of this problem like {**self.shell_defaults, **self.fetch_shell_config(self.username)} mentioned here. But the code fix should be the same anyway.

@danparizher danparizher requested a review from ntBre September 9, 2025 20:48
@danparizher
Copy link
Contributor Author

The CI failures seem to be unrelated to my changes, wondering if the one for cargo fuzz build was introduced elsewhere

@ntBre
Copy link
Contributor

ntBre commented Sep 9, 2025

Yeah no worries about the fuzz build. There was a breaking libcst release that we need to handle.

Copy link
Contributor

@ntBre ntBre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! I'll probably close and reopen to re-trigger CI, but this looks ready to go once it passes.

@ntBre ntBre closed this Sep 10, 2025
@ntBre ntBre reopened this Sep 10, 2025
@ntBre ntBre merged commit 4c64ba4 into astral-sh:main Sep 10, 2025
67 of 69 checks passed
@danparizher danparizher deleted the fix-19927 branch September 10, 2025 21:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working rule Implementing or modifying a lint rule

Projects

None yet

Development

Successfully merging this pull request may close these issues.

S602, S604, and S609 treat {**{}} as truthy

3 participants