Another newbie question
aleax at mail.comcast.net
Sun Dec 11 04:20:39 CET 2005
Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
> Right, you could use properties to make point.x get the real part of
> an internal complex number. But now you're back to point.x being an
> accessor function; you've just set things up so you can call it
> without parentheses, like in Perl. E.g.
> a = point.x
> b = point.x
> assert (a is b) # can fail
Sure -- there's no assurance of 'is' (although the straightforward
implementation in today's CPython would happen to satisfy the assert).
But similarly, nowhere in the Python specs is there any guarantee that
for any complex number c, c.real is c.real (although &c same as above).
So what? 'is', for immutables like floats, is pretty useless anyway.
> for that matter
> assert (point.x is point.x)
> can fail. These attributes aren't "member variables" any more.
They are *syntactically*, just like c.real for a complex number c: no
more, no less. I'm not sure why you're so focused on 'is', here. But
the point is, you could, if you wished, enable "point.x=23" even if
point held its x/y values as a complex -- just, e.g.,
def setX(self, x):
x.c = complex(x, self.y)
[[or use x.c.imag as the second argument if you prefer, just a style
More information about the Python-list