Skip to content

Commit 5208d45

Browse files
Technologicatclaude
Technologicat
and
claude
committed
Say that namedlambda names env-assignments in either spelling
The list of recognized forms showed only `f << (lambda ...)` for env-assignment and let bindings. Both accept `f := (lambda ...)` too, and `namedlambda` names it either way - checked by running all four forms, which come out as `f`, `g`, `h` and `k` respectively. Not a wrong statement, an incomplete one, and the incompleteness is the kind that misleads: the walrus already appears two bullets above meaning Python's own named expression, so a reader seeing `<<` alone below could reasonably conclude that `:=` in an env binding is the *other* thing and would not be named. So the note says what actually distinguishes them, which is not the operator but whether an unpythonic environment is in scope. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KXtTyQjwqYreB5KKdeE7h9
1 parent 0e6cf71 commit 5208d45

1 file changed

Lines changed: 4 additions & 0 deletions

File tree

‎unpythonic/syntax/lambdatools.py‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -98,6 +98,10 @@ def namedlambda(tree, *, syntax, expander, **kw):
9898
let syntax supported by unpythonic (here using the haskelly let-in
9999
just as an example).
100100
101+
The last two are env-assignment, which accepts ``f := (lambda ...: ...)`` as well; both spellings are
102+
named. That looks like the walrus above and is a different thing - what tells them apart is whether an
103+
unpythonic environment is in scope, not the operator.
104+
101105
Support for other forms of assignment might or might not be added in a
102106
future version.
103107

0 commit comments

Comments
 (0)