Summary
Clarify .rules/python-return.md so R503 does not require an explicit bare return in functions whose only possible result is None.
Rationale
R503 currently says “Don't rely on implicit None—always return something at the end.” This conflicts with the narrower intent expressed by R502 and led to an invalid request to add return to an all-None helper.
State the rule as:
Don't rely on implicit None if the function may return a value elsewhere—always return something at the end.
This retains the safeguard for mixed value/None control-flow while avoiding redundant bare returns for procedures.
Affected areas
.rules/python-return.md
- The R503 heading, explanation, and BAD/GOOD examples
- Alignment between R502 and R503
Acceptance criteria
- Update R503 to scope the terminal-return requirement to functions that return a value in another branch or path.
- Preserve R501’s preference for bare
return over return None.
- Make the R502 and R503 prose/examples internally consistent.
- Do not require an explicit bare
return for functions whose only result is None.
Backlinks
Summary
Clarify
.rules/python-return.mdso R503 does not require an explicit barereturnin functions whose only possible result isNone.Rationale
R503 currently says “Don't rely on implicit
None—always return something at the end.” This conflicts with the narrower intent expressed by R502 and led to an invalid request to addreturnto an all-Nonehelper.State the rule as:
This retains the safeguard for mixed value/
Nonecontrol-flow while avoiding redundant bare returns for procedures.Affected areas
.rules/python-return.mdAcceptance criteria
returnoverreturn None.returnfor functions whose only result isNone.Backlinks