Having:
self.mode = self.mode_valid(mode) return self.mode
isn't too bad.
No, not bad at all. But to me, being able to use walrus would be convenient. ——— This nuance can also be encountered in “principal use-case”. E.g.: class A: def func(self): while (self.a := 1) < 5: self.a += 1 return self.a A().func() Could be useful in iterator protocol implementations, where/or_where state is managed with property setters managing objects that implement custom `__iadd__`, etc or just simply convenience as in my former example. Same argument as for “walrus” operator itself - convenient feature. Or is there more to it? ——— I was actually surprised that this didn’t work - I thought that this operator is a literal composite of assignment and “retriever", rather than having it’s own restrictive logic. Could be a reason for it, maybe to avoid some undesirable mis-usage. But I can’t see it. Any issues arising from such construct would be the same issues as for: expr = 1 expr This could be an actual assignment + retrieval of left-hand-side, then it would work generically for all constructs, such as: a()[‘a'] := 1 a().attr := 1 If walrus currently has its own specific logic, this would integrate it nicely into assignment operator. Then it would benefit automatically from any language extension that makes use of it. Or is it already it, just with added restrictions? All in all, I think would be a generalisation of a convenience feature, which doesn’t invent anything new, but extends its convenience to more general application. These are my thoughts, whether it’s worthwhile and sensible - I have no idea. If it doesn’t break anything, doesn’t have any undesirable side effects and community likes it, then could be a good addition. Regards, DG P.S. Deferred evaluation will be able to handle this one too