> > def puzzle(*, a=>b+1, b=>a+1):
> > return a, b
> >
> > Aside: In a functional programming language
> > a = b + 1
> > b = a + 1
> > would be a syntax (or at least compile time) error.
but it's a NameError in Python, yes? or maybe an UnboundLocalError, depending on context.
> There are two possibilities: either it's a SyntaxError, or it's a
> run-time UnboundLocalError if you omit both of them (in which case it
> would be perfectly legal and sensible if you specify one of them).
This, indeed, would be similar to the behaviour of the current idiom we're trying to replace:
In [42]: def fun(a=None, b=None):
...: a = a if a is not None else b + 1
...: b = b if b is not None else a + 1
...: print(f'{a=} {b=}')
similar in the sense that whether it works or not depends on how the function is called.
In [46]: fun(3)
a=3 b=4
> I'm currently inclined towards SyntaxError,
Except that it's not invalid syntax -- as far as syntax is concerned, you can put any valid expression in there -- it's only "bad" if it happens to use a name that is also being late bound. Is there any other place in Python where a syntax error depends on what names are used (other than keyworks, of course)?
I'll leave it to folks that understand the implementation a lot better than I, but how hard would it be to make that trigger a SyntaxError?
So I vote for UnboundLocalError
since permitting it would
> open up some hard-to-track-down bugs, but am open to suggestions about
> how it would be of value to permit this.
Even if not, maybe it should raise UnboundLocalError, rather than SyntaxError
I like how it closely mirrors the current idiom, and I don't think saying that it's evaluated left to right is all that complex.
But no, I can't think of a use case :-)
-CHB