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.
> # Clearly correct behaviour
> def frob(items=[], n=>len(items)):
> def frob(items=>[], n=>len(items)):
Maybe... I'm not sure I see this as *that* much more obvious, although
I concede that the left-to-right evaluation rule implies it (it feels
like a mathematician's use of "obvious" - which quite often isn't ;-))
Using assignment expressions in argument defaults is well-defined but
not necessarily obvious in a similar way (to me, at least).
> 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.
For you, maybe. I assert that the forms above *are* confusing for me.
You're welcome to explain them to me, like you have, and maybe I'll
now remember the logic for the future, but as a data point, I stand by
my statement that these were confusing to me when I encountered them
fresh. Feel free to state that there's not *enough* cases of people
being confused by the semantics to outweigh the benefits, but it feels
to me that there are a few people claiming confusion here, and simply
saying "you shouldn't be confused, it's obvious" isn't really
addressing the point.
> > 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.
But that's not the same as you leaving the behaviour implementation
defined. In the case of operator precedence, there *is* a well-defined
answer, but the spacing doesn't match that interpretation. But in the
case of
frob(n=>len(items), items=())
you're refusing to give a well-defined semantics, and then saying that
people shouldn't do that. But unlike spacing of expressions, the order
of arguments is *important* - it is part of the API of frob that the
first positional argument is n, so "just swap the arguments" is a
semantic change. So how should people get the ("obvious") intended
behaviour? Abandon the new syntax and go back to using None as a
default? That seems a shame, given that (as I understand it) your
reference implementation works exactly as I'd want.
> 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.
You're not *just* recommending this for style guides, you're also
explicitly stating that you refuse to assign semantics to it.
Anyway, all of this is just my opinion. I'm not trying to persuade you
that you're wrong, just to point out that others see things
differently. It's up to you what you do with that information. Change
the PEP or don't, put it back into deferred status or submit it. I'm
not the decision maker here, just a community member whose feedback
will (hopefully) be considered by the SC when making the decision if
the PEP comes to them.
Paul
_______________________________________________
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/VGXSX6GDV46J7JUVOWHZPL2CO6SZYUER/
Code of Conduct: http://python.org/psf/codeofconduct/
