[EMAIL PROTECTED] (Alex Martelli) writes:
> > I could imagine using Python's built-in complex numbers to represent
> > 2D points. They're immutable, last I checked. I don't see a big
> > conflict.
>
> No big conflict at all -- as I recall, last I checked, computation on
> complex numbers was optimized enough to make them an excellent choice
> for 2D points' internal representations. I suspect you wouldn't want to
> *expose* them as such (e.g. by inheriting) but rather wrap them, because
> referring to the .real and .imag "coordinates" of a point (rather than
> .x and .y) IS rather weird. Wrapping would also leave you the choice of
> making 2D coordinates a class with mutable instances, if you wish,
> reducing the choice of a complex rather than two reals to a "mere
> implementation detail";-).
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
for that matter
assert (point.x is point.x)
can fail. These attributes aren't "member variables" any more.
--
http://mail.python.org/mailman/listinfo/python-list
