On Sat, Feb 6, 2021 at 6:08 AM Paul Sokolovsky wrote:

And looking back now, that seems like intentionally added accidental gap in the language (https://en.wikipedia.org/wiki/Accidental_gap). Similar to artificially limiting decorator syntax, which was already un-limited. But seems, there're no "lessons learned", and there's now need to wait a decade again before fixing that?

Lesson learned: Early limitations ARE easily lifted, so it's still a good idea to limit them until we've seen how they get used in practice. :)

...

The principal a.e. use in conditional expressions is testing for non-nullness. Your

...

while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: a2 = a1 + 1 b2 = b1 + 1

is an unusual and very specific use.

Well, many people were thinking (and I bet still think) that ":=" itself is very unusual case. But if it's in, why not make it consistent with the assignment statement and unleash the full power of it?

TBH I don't think I'm understanding the use-case here, because it looks like it'd work just fine with fewer variables and a cleaner rendition: while a1 < 5: a1, b1 = phi([a0, a1], [b0, b1]) a1 += 1 b1 += 1

Right, but I started my original email with "I finally found a usecase where *not* using assignment expression is *much* worse than using it."

"Much worse" doesn't fit with what I would write that code as, so I must have misunderstood your code somewhere. ChrisA

On Sat, Feb 6, 2021 at 5:21 PM Random832 wrote:

While we're on the subject of assignment expression limitations, I've occasionally wanted to write something like

try: return a_dict[key] except KeyError: return (a_dict[key] := expression to construct value)

That's what the __missing__ method is for. ChrisA

Hello, On Sat, 6 Feb 2021 06:17:08 +1100 Chris Angelico wrote:

On Sat, Feb 6, 2021 at 6:08 AM Paul Sokolovsky wrote:

...

And looking back now, that seems like intentionally added accidental gap in the language (https://en.wikipedia.org/wiki/Accidental_gap). Similar to artificially limiting decorator syntax, which was already un-limited. But seems, there're no "lessons learned", and there's now need to wait a decade again before fixing that?

Lesson learned: Early limitations ARE easily lifted, so it's still a good idea to limit them until we've seen how they get used in practice. :)

Well, I wish there was also a bit of "try to make things consistent from the beginning", because "easily lifted" is a bit optimistic characterization. That said, that's meta-level thought, down to earth case is that I indeed would like to start talks on actually extending walrus syntax to accept tuple/list on LHS. I've now triaged https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=walrus&submit=search&status=-1%2C1%2C2%2C3 and see that the only case it was mention is https://bugs.python.org/issue42295 , which was a case of walrus precedence confusion. I thus submitted https://bugs.python.org/issue43143 for future reference.

...

...

The principal a.e. use in conditional expressions is testing for non-nullness. Your

...

while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: a2 = a1 + 1 b2 = b1 + 1

is an unusual and very specific use.

Well, many people were thinking (and I bet still think) that ":=" itself is very unusual case. But if it's in, why not make it consistent with the assignment statement and unleash the full power of it?

TBH I don't think I'm understanding the use-case here,

I hope we understand that we go into rabbit hole of discussing a specific case, whereas I reported a general limitation, and tried to back it with more or less general example (i.e. not a once-off case, with the "SSA conversion" usecase, each and every while would be affected). With that in mind, I guess it's fine for python-ideas to discuss that particular usecase in detail.

because it looks like it'd work just fine with fewer variables and a cleaner rendition:

while a1 < 5: a1, b1 = phi([a0, a1], [b0, b1]) a1 += 1 b1 += 1

Let's first note that you omitted the initialization of a0 and b0 which was in my example. And with that in mind, you'll immediately see what's wrong with your code: it tries to access uninitialized a1. That's on first loop iteration. On next, it will test *old* value of a1, whereas it should test already updated value. That's why it really has to assign new values in the loop's condition expression: while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: (of course, if you're careful, you'll notice that a2, b2 are initialized on 1st iter, so assume there're initialized as: a2 = b2 = __undef__ Where __undef__ causes exception on any operation with it. )

...

Right, but I started my original email with "I finally found a usecase where *not* using assignment expression is *much* worse than using it."

"Much worse" doesn't fit with what I would write that code as, so I must have misunderstood your code somewhere.

*My* motivation is "SSA is already pretty complex conversion, so it would be nice to avoid *additional* Python source transformations not related to SSA per se, especially if Python generic syntax now allows that". But, again, it's just an example case. I use it to illustrate an apparent gap in ":=" functionality comparing to "=", and propose to lift that restriction.

ChrisA

[] -- Best regards, Paul mailto:pmiscml@gmail.com

On Sat, Feb 6, 2021 at 8:54 PM Paul Sokolovsky wrote:

Hello,

On Sat, 6 Feb 2021 17:26:00 +1100 Chris Angelico wrote:

...

On Sat, Feb 6, 2021 at 5:21 PM Random832 wrote:

...

While we're on the subject of assignment expression limitations, I've occasionally wanted to write something like

try: return a_dict[key] except KeyError: return (a_dict[key] := expression to construct value)

That's what the __missing__ method is for.

That's true, but that would be an argument against PEP572 ;-).

PEP 572 was never meant to replace all other ways of doing things, and __missing__ is exactly the tool for this job :)

But we live in a world where PEP572 is a reality, and people start to look how to get the most juice out of it.

Why? Just because it's there?

While triaging the issue with parallel assignments, I saw there's already pretty long trail of elaboration of ":=" for various cases where original implementation forced parens, which were looking weird to human eye, e.g.:

https://bugs.python.org/issue42316 https://bugs.python.org/issue42374 https://bugs.python.org/issue42381

My proposal is to file parallel assignment case into the same "inital omission" department like the above. And just like the above, it seems it would be a trivial grammar fix (I didn't run the whole testsuite on the result yet though ;-) ).

The omission was intentional, and so far, I'm not seeing a justification for reversing that decision :) ChrisA

On Mon, Feb 8, 2021 at 4:21 PM Random832 wrote:

...

On Sat, Feb 6, 2021 at 5:21 PM Random832 wrote:

...

While we're on the subject of assignment expression limitations, I've occasionally wanted to write something like

try: return a_dict[key] except KeyError: return (a_dict[key] := expression to construct value)

On Sat, Feb 6, 2021, at 01:26, Chris Angelico wrote:

...

That's what the __missing__ method is for.

Requires a dict subclass

That shouldn't be a big deal in most situations.

Requires that the value be determinable from the key alone [rather than any other variables available in the function containing the above code]

True, but in many situations that IS the case. You're stipulating a situation where: 1) The construction isn't a simple no-arg function (so you can't use defaultdict) 2) The construction can't be figured out from the key alone 3) The cost of construction is high (so you can't use setdefault) 4) There are multiple places where you'd want this behaviour (so you can't just try/except it) Seems a tad narrow to me. Got an actual use-case for this?

On Sat, Feb 6, 2021, at 01:50, Brendan Barnwell wrote:

...

You can already do that with `return a_dict.setdefault(key, your_expression_here)`. If the expression is expensive to evaluate you can use a short-circuiting conditional expression to guard it.

How exactly would you use a short-circuiting conditional expression to do this?

If you're suggesting `... if key not in a_dict else ...` this creates a race condition, and also involves checking the key in the dictionary twice.

Only against deletion. You could use: a_dict[key] if key in a_dict else a_dict.setdefault(key, big_long_epr) and you're guaranteed that it will use the existing value if it exists. It's possible that the key exists at the condition and then has been deleted before the subscript, but then you have to ask what would happen if you did a regular setdefault and then the key was deleted, and at this point, it's entirely down to the application's semantics (what does it MEAN if something's been deleted while something else is trying to auto-add it?). Checking if a key is in a dict is extremely cheap. Dicts are fundamental to Python, and every implementation will have a highly optimized dict such that you shouldn't need to worry about that kind of cost.

Perhaps a constructdefault method could be added to dict, broadly equivalent to

def constructdefault(self, func): try: return self[key] except KeyError: return (self[key] := func())

you could use self[key] = value = func(); return value; and the same in the original [not part of dict class] snippet I posted above, but the point is this seems so much like exactly the sort of use case that := is intended for, that it comes across as weird that it's not usable.

During discussion of PEP 463, one of the points raised was that many situations like this might be better spelled as exception expressions. That was largely shot down by the fact that, in actual usage, methods like setdefault are FAR easier to work with. I think the same applies here; rather than shoehorning assignment expressions into this job, figure out why it is that both __missing__ and setdefault() aren't suitable, and see if THAT problem can be solved. I've been using assignment expressions since they were added to the language (my primary Python interpreter has, for a number of years, been a master branch build), and they've been incredibly useful, but I have never once run into a situation where the restrictions cause me problems. ChrisA