On 26/10/2021 18:25, Chris Angelico wrote:
On Tue, Oct 26, 2021 at 11:10 PM Steven D'Aprano <st...@pearwood.info> wrote:
Based on the multi-pass assignment model, which you still favour,
those WOULD be quite inconsistent, and some of them would make little
sense. It would also mean that there is a distinct semantic difference
between:
def f1(x=>y + 1, y=2): ...
def f2(x=>y + 1, y=>2): ...
Sure. They behave differently because they are different.
These are different too:
# Block 1
y = 2
x = y + 1
# Block 2
x = y + 1
y = 2
Yes, those ARE different. Those are more equivalent to changing the
order of the parameters in the function signature, and I think we all
agree that that DOES make a difference. The question is whether these
could change meaning if you used a different type of assignment, such
as:
y := 2
x = y + 1
Does that suddenly make it legal? I think you'll find that this sort
of thing is rather surprising. And that's what we have here: changing
from one form of argument default to another changes whether
left-to-right applies or not.
I don't want that. And based on an experiment with a less-experienced
Python programmer (admittedly only a single data point), neither do
other people. Left-to-right makes sense; multi-pass does not.
As I may be the data point in question: One of my posts seems to have
got lost again, so I reproduce some of it (reworked):
What I DON'T want to see is allowing something like this being legal:
def f(a := b+1, b := e+1, c := a+1, d := 42, e := d+1):
If no arguments are passed, the interpreter has to work out to evaluate
first d, then e, then b, then a, then finally c. If some arguments are
passed, I guess the same order would work. But it feels ... messy. And
obfuscated.
And if this is legal (note: it IS a legitimate use case):
def DrawCircle(centre=(0,0), radius := circumference / TWO_PI,
circumference := radius * TWO_PI):
the interpreter has to work out whether to evaluate the 2nd or 3rd arg
first, depending on which is passed.
AFAICS all this may need multiple passes though the args at runtime.
Complicated, and inefficient. *If* it could all be sorted out at
compile time, my objection would become weaker.
There has been support for evaluating all early-bound defaults before
all late-bound defaults. I have been persuaded that this is a
reasonable option. AFAICS there would be little practical difference
from straight left-to-right evaluation of defaults, since assigning an
early-bound default should not have a side effect. So it could even be
an implementation choice.
Best wishes
Rob
PS Can I echo Guido's plea that people don't derail this PEP by trying
to shoehorn deferred-evaluation-objects (or whatever you want to call
them) into it? As Chris A says, that's a separate idea and should go
into a separate PEP. If I need a screwdriver, I buy a screwdriver, not
an expensive Swiss Army knife.
_______________________________________________
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/24LBACW5J4JXGTAXF5BLDPGMB3LU2HBI/
Code of Conduct: http://python.org/psf/codeofconduct/
