Op 2005-11-14, Mike Meyer schreef <[EMAIL PROTECTED]>: > Antoon Pardon <[EMAIL PROTECTED]> writes: >> Op 2005-11-10, Mike Meyer schreef <[EMAIL PROTECTED]>: >>> [Context recovered from top posting.] >>> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: >>>> Daniel Crespo wrote: >>>>> Well, I hope that newcomers to Python don't confuse himselves :) >>>> This mutable/immutable object and name/variable is confusing. >>> Only if you have to overcome a conviction that variables behave in a >>> different way. If you've never seen them behave another way, or have >>> already gotten used to this model from another language (it dates back >>> to the 60s, if not the late 50s), then it's no problem. I'm sure the >>> problem exists in the opposite direction, except that few people >>> travel that route. >>> Most OO languages do the name/variable thing, but some of the popular >>> ones aren't consistent about it, giving some types "special" status, >>> so that sometimes "a = b" causes b to be copied onto a, and sometimes >>> it causes a to become a pointer to b. I find a consistent approach is >>> preferable. >> But what about a consistent approach, that allows choice. > > It's been done in other languages. But it requires more care than one > would think.
That is possible. >> Like having an assignment operator (let use @= for it) next to a >> (re)bind operator. >> >> We could then have something like the following. >> >> a = 5 >> b = a >> a @= 7 >> b ==> would result in 7. > > You've just overwritten the object referred to by the token "5" in the > source code with the value 7, so you get: > > print 5 > 7 > > Not exactly a desirable outcome, but some language implementations > have allowed this kind of thing in the past. You either have to make > all objects mutable, or disallow assignment to immutable objects, > which sort of defeats the purpose. You have a valid point, but I think a different approach is possible. Don't make the distinction between mutable and immutable types but between mutable and immutable objects. So an int wouldn't be an immutable type, but 5 would be an immutable object. So the code above I gave would throw an exception, but the following might work. a @= 5 b = a b @= 7 a ==> would result in 7. > Another approach is to have a special object type if you want to allow > assignment to the object it refers to. That's what Python does now, it > just doesn't have a syntax just to support that. If it did, your > example might look like: > > a := 5 > b = @a > a := 7 > @b ==> would result in 7 Could it also work the other way? By somehow manipulating b change a? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
