So obvious! Now I cannot understand why I got it backwards. I will delete my comment, it makes no sense. Thanks for notifying me quickly.
My idea was not to have to type twice e.g. the some.source[key] in:
value = some.source[key]
some.source[key] = processed(value)
and thought the assignment target is a suitable tool for that.
Would (or should) it? a.b[c].d = @ + 1 looks much more like a.b[c].d = a.b[c].d + 1 (which evaluates a.b[c] twice) than a.b[c].d += 1.
I don’t see the loss in clarity when reading the code outweighed by the benifits in writing the code. Honestly, I still don’t know what
call_with_local_args(some_target=@)
is doing.
Decades ago, about -1 BP (before Python) I was helping a newbie with C. I remember explaining that it was tricky because asterisk “*” did at least 4 different things, depending on where it was placed. (Pointer / deference / multiply / ).
Of all the variants suggested, only the right hand side (RHS) dunder __target__ makes sense to me. __tgt__ would save few characters and be consistent with eq, lt, str, del, len.
I think it’s important to keep in mind that some future person will be learning Python some day, and the more esoteric symbols the steeper the curve to get initially competent.
long_name as x overlaps with context manger usage
with open("data") as f:
so it would slow down my comphrension of code on first read.
It won’t start with with and will be immediately followed by = (or maybe an augmented assignment operator?), not :, so I don’t think it would be too bad.
I’m not sure why I’m hung up on this detail, but when would @/__target__ be replaced by the appropriate target? The tokenizer could make the replacement immediately, so that it’s not visible in, for example, the AST. The parser could make the replacement so that it’s not visible to the code generator. The code generator could replace it so that the resulting code is the same. (I’m not immediately picturing a scenario where a new byte code is necessary.)
I’m at best +0 on the proposal, though.
Since the goal is to evaluted the start of the core of the expression (and I assume the subscript arguments as well) only once, the only sensible option is in the code generator. Tokenizer and AST transformations would be very complex.
The meaning is nearly the same in both. If anything, your comprehension is more robust. Notation that gets used in slightly different contexts, but the praxis is similar, it helps to use it and think about the subject. Examples abound: a^ba^c=a^{b+c} and f^a\circ f^b=f^{a+b}, \frac{a}{b}\frac{b}{c}=\frac{a}{c} and \frac{dz}{dy}\frac{dy}{dx}=\frac{dz}{dx}, all the different meanings that a+b, A+B, A\oplus B have and the same with \cdot,*, \times, \otimes.
Some history worth considering on this topic:
as for decent reasons: PEP 572 – Assignment Expressions | peps.python.orgI also tried to find some of the old python-ideas threads kicking around possible ways improving namedtuple declarations, but didn’t come up with any relevant links (it’s possible those were long enough ago that they were directly on python-dev, so a bit more effort might find them)
(The statement local namespaces idea could be genuinely interesting to revisit in light of PEP 709 – Inlined comprehensions | peps.python.org, since it could ditch the awkward question mark syntax in favour of simple variable references that the compiler is able to process correctly, which would also help resolve some of the scoping rules since it wouldn’t need to use a closure anymore. The “soft keyword” concept would also help a lot. I’d suggest a new PEP called “statement local variables” rather than attempting to resurrect the old PEP, though)