On Sat, 18 Jun 2022 at 06:17, Brendan Barnwell <brenb...@brenbarn.net> wrote: > > On 2022-06-17 07:53, Chris Angelico wrote: > > On Sat, 18 Jun 2022 at 00:21, Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >> On Fri, 17 Jun 2022 at 14:15, Chris Angelico <ros...@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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/A3WKRWHPTDGF5ZM3PPICY563SDYJ3H4V/ Code of Conduct: http://python.org/psf/codeofconduct/
