On Tue, Oct 26, 2021 at 11:10 PM Steven D'Aprano <steve@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
On 26/10/2021 18:25, Chris Angelico wrote: 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.