Suggesting for overloading the assign operator

[Bengt Richter]

On Tue, 1 Jul 2003 09:22:03 -0600, Steven Taschuk <staschuk at telusplanet.net> wrote:

>Quoth Rim:
>  [...]
>> The idea is to separate the value assignment from the type assignment,
>> by introducing a new operator, let's say the ':=' operator.
>> 
>> '=' remains what it is, assigns type and value at the same time
>> ':=' assigns only the value
>
>That's a peculiar way of speaking.  '=' does not assign type and
>value to a variable; it assigns an object to a name.
>
>  [...]
>> In reality, := would just coerce the return type of the RHS of := to
>> the type of the variable on the LHS of the :=, preserving the value(s)
>> as best as it can.
>
>"The type of the variable" is not a meaningful phrase in Python:
>names do not have types; objects do.  I assume you meant "the type
>of the object the name on the lhs is presently bound to".
>
>Coerce how?  Do you want a new __magicmethod__ for this operation?
>
>Would ':=' mutate the object presently bound to the lhs name
>create a new object and rebind the lhs name?  To be concrete:
>
One thought would be that it wouldn't change the current binding. E.g.,

    x := y

could be a spelling of x.__update__(y) and would be an *expression* with
potential side effects. By convention, a reference to the updated same object
would be returned. I.e., x.__class__ would have to have

    def __update__(self, other):
        <optional use of other>
        return self

For starters, you could just let AttributeError get raised if there's no __update__ method.

>    a = whatever
>    b = a
>    a := 7
>    assert a is b
>
>Should that assertion succeed or fail, in general?  (Note that it
>fails in general if the ':=' is replaced with '=', even if
>whatever == 7.)

For the above, it should succeed, since the binding will have been unchanged
>
>Would ':=' support chaining?  That is, would
>    a := b := <some expression>
>work?  If so, would it be equivalent to
Yes, it should work, but no, it wouldn't be equivalent to
>    _tmp = <some expression>
>    a := _tmp
>    b := _tmp
working left to right, it would presumably be equivalent to

     a.__update__(b).__update__(<some expression>)

>(except for the namespace pollution), to match the semantics of
>chained '='?  (Note that the assignments happen left to right.)
>
>Would use of a name on the lhs of a ':=' cause that name to be
>considered local, as such use with '=' does?
No, because it would be a named object reference for the purpose of looking
up the __update__ attribute in the non-sugar spelling of a:=b (which
is a.__update__(b)) -- i.e., it's an expression, not really an assignment statement.

>
>> If the type of the variable was still undefined, ':=' would behave
>> like '='. It might create confusion in future code, but does not break
>> old code.
>
>Yikes.  Why not raise NameError if the name on the lhs of ':=' is
>not yet bound?
Yes.

>
>> I think it would be a nice feature to have. Comments?
>
>Your example
>    a = Currency(6)
>    a := 7
>is highly strange.  (Even if we ignore the question of *which*
>currency is being represented; the example could easily be
>restated with, say, FixedPoint or Rational or some such.)
>
I don't know that I would totally dismiss the usage. It could be
a concise notation for a possibly polymorphic update operation.

    w = Widget(blah, blah)
    w := ('blue','white')  # changes fg/bg colors
    w := (20,40) # changes position
    w := Font('Times Roman', size=24)
    w := 'some text appended to a text widget'

Of course, you could use a property very similarly, e.g.,
    w.p = 'text ...'

I guess it's a matter of what kind of sugar you like ;-)

>How is it that your users are happy to write Currency(...) when
>first assigning to a name, but not happy doing so when assigning
>later?
>
>Do they not understand that '=' binds a name to an object?  Are
>they C programmers who think of assignment as copying a value from
>one location in memory to another?  Do they think of the first
>assignment as a type declaration for the name?  (If any of these
>three are true, they need to be better educated -- they're all
>fundamental misconceptions about Python.)
True, but if they did understand that a=b binds but a:=b updates??

>
>Do they need a language with syntactic support for Currency
>objects?
I'm not sure what that would mean.

OTOH, a:=b might lead to analogies with a+=b and other a<op>=b
and then where would we be ;-)

Let's see...

    a+:=b => a.__update__(a.__add__(b))

?? ;-)

Regards,
Bengt Richter