...

From: kirby urner [mailto:kirby.urner@gmail.com]

Complex x = new Complex (); x.real = 1.0; x.imag = 2.0; Complex y = new Complex (3.0, 4.0);

Yes, that's a change-in-place ability, true.

Kirby

And exactly what I need to have my Complexes do the PyGeo dance. Art

So we have different levels of mutability. A complex type which doesn't allow resassignment of real and imaginary parts might look like: Immutable: c = Complex(1,2) c = c.real(3) # assigning a new value c = c.imag(4) # yet another new value Mutable: c = Complex(1,2) c.real = 3 c.imag = 4 Even more mutable: c + c # changes c to 2c c**2 # 2nd power of c (changes c "in place") All are codable in Python of course. Of these three possibilities, my own bias is in favor of the least mutable (top example). Arthur is proposing first level mutability (2nd example). I doubt any of us like the 3rd level. Am I right? Note that Python's built-in complex number doesn't even allow the top example. Instead, one might go: Even more immutable: c = Complex(1,2) c = Complex(3, c.imag) # assigning a new value c = Complex(c.real, 4) # yet another new value So obviously there's a spectrum here. Python supports them all, with coding. Kirby

On 3/28/06, John Zelle <john.zelle@wartburg.edu> wrote:

On Tuesday 28 March 2006 09:42, kirby urner wrote:

...

So we have different levels of mutability. A complex type which doesn't allow resassignment of real and imaginary parts might look like:

Immutable:

c = Complex(1,2) c = c.real(3) # assigning a new value c = c.imag(4) # yet another new value

Actually is a mutable version. Allowing the change to the components after creation makes it mutable. It does not matter if the change is through mutating methods or by direct attribute access. The point is that the object itself changes. If two variables reference the same object (or two threads manipulate it) they will both see the changes.

An immutable complex would simply disallow changes. To "change" either component would require creation of a new object.

But the above doesn't allow any change to a complex number. Rather, c.imag(3) outputs a new complex number, leaving c unchanged. Except I immediately reassign the new value to c. Something like: class Complex(object): def __init__(self, v, z): self.r = v self.i = z def imag(v): return Complex(self.r, v) def real(v): return Complex(v, self.i) # plus code to make i, r read-only. Just plain c.imag(3) would not change c, plus the returned value would be lost, given there's no assignment. Sorry if my example was unclear. Kirby

More generally, Python supports programmer freedomn, and accepts the cost of that freedom. If we don't exercise that freedom, Python - it seems to me - is a losing proposition.

Art

Programmer freedom means more opportunities to shoot oneself in the foot with bad designs. Exercising freedom doesn't have to mean suspending one's judgment as to what's a pitfall. Kirby

----- Original Message ----- From: kirby urner <kirby.urner@gmail.com>

Programmer freedom means more opportunities to shoot oneself in the foot with bad designs.

You certainly don't need to confront that issue in the typical Urner 10 line script. Though I am not sure I can imagine something worse than your @property laden triangle in so many lines. You might have more sympathy for what I am confronted with if you went a little further. Its that damn 11th line that's the killer. Sorry Dethe. Art