On Sat, 18 Jun 2022 at 06:17, Brendan Barnwell <brenbarn@brenbarn.net> wrote:
On 2022-06-17 07:53, Chris Angelico wrote:
On Sat, 18 Jun 2022 at 00:21, Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 17 Jun 2022 at 14:15, Chris Angelico <rosuav@gmail.com> wrote:
There are several ways to make this clearly sane.
# Clearly UnboundLocalError def frob(n=>len(items), items=>[]):
Um, I didn't see that as any more obvious than the original example. I guess I can see it's UnboundLocalError, but honestly that's not obvious to me.
Question: Is this obvious?
def f(): x, x[0] = [2], 3 print(x)
def boom(): x[0], x = 3, [2] # raises UnboundLocalError
Personally, I don't care so much whether the behavior is "obvious" or even "confusing" as about whether it's defined. Both of those examples have defined behavior in Python. That's better than having undefined behavior where either of them might do different things depending on the implementation.
It's unfair to say that I "refuse to assign semantics" as if I'm permitting literally any behaviour. All I'm doing is saying that the UnboundLocalError is optional, *at this stage*. There have been far less-defined semantics that have remained in the language for a long time, or cases where something has changed in behaviour over time despite not being explicitly stated as implementation-defined. Is this legal?
def f(): x = 1 global x
Does Python mandate whether this is legal or not? If so, how far back in Python's history has it been defined?
If it doesn't mandate it, then it would be better if it did. In my view, none of your arguments about "some things are undefined" are actually providing any positive support for the idea that the behavior in question should remained undefined in the PEP.
I've just pushed a change to the wording. Let's see if it makes a difference.
I think the PEP would benefit from a fully explicit definition of exactly when and how the late-bound defaults would be evaluated. For instance, by demonstrating an "unrolling" into something paralleling existing Python code. Like:
def f(a=>items[0], items=[]): # body
is equivalent to:
def f(a=FakeDefault, items=[]): a = items[0] # body
That IS in the PEP. Have you read it?
. . . or whatever. I mean, it's up to you as the PEP author to decide what semantics you want. But I think the PEP should be fully explicit about the order of evaluation of everything. I don't see any benefit to leaving it ambiguous.
Read the latest version and tell me if it still sounds ambiguous.
This is all academic to me, however, since even if you did that I still wouldn't support the PEP for various more basic reasons that I've mentioned in the earlier iteration of this thread.
And there we have it. People are complaining loudly, but then ALSO saying that they don't support the proposal anyway. Why are you bothering to debate this if you've already made your decision? ChrisA