On Fri, 17 Jun 2022 at 23:05, Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 17 Jun 2022 at 13:54, Andrew Jaffe <a.h.jaffe@gmail.com> wrote:
Is there a *reason* why you are leaving this unspecified? To put it more baldly, is there any reason (e.g., difficulty of parsing?) why allowing these "forward" references should *not* be allowed? It seems that "n=>len(items), items=[]" might be an important use case.
Am I right in thinking the key issue here is that => is *not* used for "items"? So
def frob(n=>len(items), items=[]): print(n) items.append(1)
gets very complicated to reason about. What does this print?
There are several ways to make this clearly sane. # Clearly UnboundLocalError def frob(n=>len(items), items=>[]): # Clearly correct behaviour def frob(items=[], n=>len(items)): def frob(items=>[], n=>len(items)): The only way for it to be confusing is to have => on one argument and then = on a subsequent argument, *and* to have the earlier one refer to the later one.
Even if someone *can* provide an answer, I'd be reluctant to accept that any answer could be described as "intuitive". And "well, don't do that" is just ducking the question - in essentially the same way as "it's implementation defined" does...
But "don't do that" is a perfectly reasonable response to other kinds of bad code, like messing up your spacing: x = 1+2 * 3+4 Is this intuitive? Some people will think that x should be 21, but the actual answer is 11. Python won't stop you from doing this, but style guides absolutely should. In the same way, I would strongly recommend that style guides frown upon referring to arguments later in the parameter list, even if it happens to be legal. I'm just not mandating that the language check for this and artificially block it. ChrisA