Title: During a recent HN discussion about the walrus operator I came to realize yet another advantage of notation.  I used APL professionally for about ten years, which made it an obvious source of inspiration for an example that, in my opinion, demonstrates why the Python team missed a very valuable opportunity to take this wonderful language and start exploring the judicious introduction of notation as a valuable tool for thought (borrowing from Ken Iverson&#x27;s APL paper with that title [0]).<p>To simplify, I&#x27;ll define the desire for this walrus operator &quot;:=&quot; as &quot;wanting to be able to make assignments within syntax where it was previously impossible&quot;:<p><pre><code>    if x = 5    # was impossible

    # and now

    if x := 5  # makes is possible
</code></pre>
A more elaborate example given in the PEP goes like this:<p><pre><code>    Current:

    reductor = dispatch_table.get(cls)
    if reductor:
        rv = reductor(x)
    else:
        reductor = getattr(x, &quot;__reduce_ex__&quot;, None)
        if reductor:
            rv = reductor(4)
        else:
            reductor = getattr(x, &quot;__reduce__&quot;, None)
            if reductor:
                rv = reductor()
            else:
                raise Error(
                    &quot;un(deep)copyable object of type %s&quot; % cls)

    Improved:


    if reductor := dispatch_table.get(cls):
        rv = reductor(x)
    elif reductor := getattr(x, &quot;__reduce_ex__&quot;, None):
        rv = reductor(4)
    elif reductor := getattr(x, &quot;__reduce__&quot;, None):
        rv = reductor()
    else:
        raise Error(&quot;un(deep)copyable object of type %s&quot; % cls)
 
</code></pre>
At first I thought, well, just extend &quot;=&quot; and be done with it.  The HN thread resulted in many comments against this idea.  The one that made me think was this one [1]:<p><pre><code>    These two are syntactically equal and in Python there&#x27;s no 
    way a linter can distinguish between these two:

        if reductor = dispatch_table.get(cls):
        if reductor == dispatch_table.get(cls):
    
    A human being can only distinguish them through careful inspection. 
    The walrus operator not only prevents that problem, but makes 
    the intent unambiguous.
</code></pre>
Which is a perfectly valid point.  I get it.<p>Still, the idea of two assignment operators just didn&#x27;t sit well with me.  That&#x27;s when I realized I had seen this kind of a problem nearly thirty years ago, with the introduction of &quot;J&quot;.  I won&#x27;t get into the details unless someone is interested, I&#x27;ll just say that J turned APL into ASCII soup.  It was and is ugly and it completely misses the point of the very reason APL has specialized notation; the very thing Iverson highlighted in his paper [0].<p>Back to Python.<p>This entire mess could have been avoided by making one simple change that would have possibly nudged the language towards a very interesting era, one where a specialized programming notation could be evolved over time for the benefit of all.  That simple change would have been the introduction and adoption of APL&#x27;s own assignment operator: &quot;←&quot;<p>In other words, these two things would have been equivalent in Python:<p><pre><code>    a ← 23

    a = 23
</code></pre>
What&#x27;s neat about this is that both human and automated tools (linters, etc.) would have no problem understanding the difference between these:<p><pre><code>    if reductor ← dispatch_table.get(cls):
    if reductor == dispatch_table.get(cls):
</code></pre>
And the larger example would become this:<p><pre><code>    if reductor ← dispatch_table.get(cls):
        rv ← reductor(x)
    elif reductor ← getattr(x, &quot;__reduce_ex__&quot;, None):
        rv ← reductor(4)
    elif reductor ← getattr(x, &quot;__reduce__&quot;, None):
        rv ← reductor()
    else:
        raise Error(&quot;un(deep)copyable object of type %s&quot; % cls)
</code></pre>
This assignment operator would work everywhere and, for a period of time, the &quot;=&quot; operator would be retained.  The good news is that old code could be updated with a simple search-and-replace.  In fact, code editors could even display &quot;=&quot; as &quot;←&quot; as an option.  The transition to only allowing &quot;←&quot; (and perhaps other symbols) could be planned for Python 4.<p>Clean, simple and forward-looking.  That, to me, is a good solution.  Today we have &quot;=&quot; and &quot;:=&quot; which, from my opinionated perspective, does not represent progress at all.<p>[0] <a href="http:&#x2F;&#x2F;www.eecg.toronto.edu&#x2F;~jzhu&#x2F;csc326&#x2F;readings&#x2F;iverson.pdf" rel="nofollow">http:&#x2F;&#x2F;www.eecg.toronto.edu&#x2F;~jzhu&#x2F;csc326&#x2F;readings&#x2F;iverson.pd...</a><p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21426338" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21426338</a>
Upvote: