Suggesting for overloading the assign operator
Steven Taschuk
staschuk at telusplanet.net
Tue Jul 1 11:22:03 EDT 2003
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.
More information about the Python-list
mailing list