Suggesting for overloading the assign operator

[Steven Taschuk]

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:

    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.)

Would ':=' support chaining?  That is, would
    a := b := <some expression>
work?  If so, would it be equivalent to
    _tmp = <some expression>
    a := _tmp
    b := _tmp
(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?

> 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?

> 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.)

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.)

Do they need a language with syntactic support for Currency
objects?

-- 
Steven Taschuk                            staschuk at telusplanet.net
"Our analysis begins with two outrageous benchmarks."
  -- "Implementation strategies for continuations", Clinger et al.