Is it just Syntactic Sugar ?

[Thomas Wouters]

On Tue, May 30, 2000 at 02:24:19PM -0700, Johann Hibschman wrote:

> I still see this as a macro-like method.  And, yes, what you've
> outlined does seem like the proper way to expand the macro, will full
> gensym-ing and all.  But it still calls the simple "+" operator on the
> object returned by t1[t2], not some form of t1[t2].incr(e), which is
> what I'd understood Thomas Wouters to be asking for.

I'll reply to this post instead of the longer one, because you *almost*
understand my meaning now ;-) I'm not asking for a 't1[t2].incr(e)'.
Instead, I'm asking for a method exactly like __add__ that realizes that the
caller actually wants to replace the current object with the new object. It
shouldn't matter [to the definition] wether the object is changed in place,
and returns self, or creates a new object just like __add__, and returns
that. Indeed, if there is no __add_in__ or whatever the magic method would
be called, it could just call __add__, to simulate imutability. (Instead of
modifying in-place, it would be exactly like a 'macro rewrite', in that
case, except that the lookup is done only once.)

Hey, it isn't written yet (not with the __magic__ anyway), so I dont know
wether it'll work out. But my intuition says it will; x += 1 will be
something *different* than x = x + 1, if x so wants it. I think it fits
nicely into Pythons' ideas mutability and assignment.

Okay, there might be some confusion with the fact that you can't see from
the statement wether an object is modified or a new one is created, so that
you can't see if another reference to the object still references the same
object afterwards, but I *think* it won't be much more complicated than that
issue already is.

We'll-have-to-wait-for-someone-to-actually-write-it-and-see-ly yr's,

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!