Curious assignment behaviour

[Tim Peters]

[Dale Strickland-Clark]
> ...
> So how about an alternative assignment operator that can't be confused
> with equality but which yeilds the assigned value?
>
> Pascal uses :=

But doesn't allow it in expressions -- assignment in Pascal is also a
statement.

> Another language (I forget which) uses <-
>
> (I've always prefered := for assignment and a plain = for equality.)
>
> I don't suppose I'm the first to suggest this, either.

Bingo:  it's been suggested countless times over the last decade, but before
the introduction of PEPs there's no coherent historical record. Searching a
comprehensive archive is the only tool.  Guido's first public word on the
topic appears to be msg #54 (of 161,909 in the egroups/Yahoo archive):

    http://groups.yahoo.com/group/python-list/message/54

    I agree, reluctantly (because of all the lines of library and
    example code I will have to change), that this change should be made;
    but it won't be in 0.9.4 if I release that soon.  Note that this
    still won't give you assignments in expressions as side effects; I
    am against such a feature even though it occasionally saves a line of
    code -- one of Python's strong points is that it is usually very easy
    (and pretty!) to read, and I feel that assignments in expressions
    would have a strong negative effect on readability (and prettiness!).

The change he was talking about (affecting "all the lines of library and
example code I will have to change" -- probably amounted to a few hundred at
the time <wink>) was introducing "==" to mean equality in Python.  At the
start, "=" meant both equality-testing and assignment.  A consequence was
that, and especially in interactive mode,

>>> a = b

was ambiguous.  So that didn't last.

In later years, an informal proposal to add ":=" for embedded assignment
made significant progress, but floundered over a combination of ugliness and
lack of consensus.  The most popular variant had ":=" binding tightly, so
that e.g.

    while myvar := func() != 0:

assigned myvar to func's return value, not to the Boolean outcome.  But then

    if distance_sq := x**2 + y**2 < 1:

bound distance_sq to x**2, not to the sum.  Etc.  For every hack to the
precedence rules someone suggested, someone else came up with a natural
example where it was plain surprising.  IIRC, this line ended when it was
more-than-less agreed that any use of ":=" would *require* surrounding
parentheses.  But that made it even uglier, and proponents got rarer while
the opposition enjoyed a major resurgence in the polls <wink>.

so-its-prospects-look-dim-even-if-it-had-a-pep-ly y'rs  - tim