(I'm sorry for my delayed response -- I've been travelling and not had
reliable Internet access.)
On 2011-12-25, Ian Kelly wrote:
> On Thu, Dec 22, 2011 at 1:21 AM, Spencer Pearson
> wrote:
>> I see a problem with this, though. The intersection of two lines is
>> (usually) an object of type Point
On Dec 25 2011, 2:58 pm, Terry Reedy wrote:
> On 12/24/2011 6:49 PM,SpencerPearsonwrote:
>
> > On Dec 23, 9:13 am, Terry Reedy wrote:
> >> On 12/22/2011 3:21 AM,SpencerPearsonwrote:
>
> >>> I'm writing a geometry package, with Points and Lines and Circles and
> >>> so on, and eventually I want to
(I'm sorry for my delayed response -- I've been travelling and not had
reliable Internet access.)
>> Spencer, i would re-think this entire project from the
>> beginning. You are trying to make an object out of everything. You
>> don't need to make an object of EVERYTHING.
>
> Very true.
I'm not s
On Mon, Dec 26, 2011 at 12:46 AM, Steven D'Aprano
wrote:
> class DrawableLine(Line):
> intersection_kind = DrawablePoint
Ha! That works. I was sure there'd be some simple way to do it!
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, 26 Dec 2011 00:37:22 +1100, Chris Angelico wrote:
> On Mon, Dec 26, 2011 at 12:27 AM, Steven D'Aprano
> wrote:
>> There's nothing in the above that assumes that other has the same type
>> as self. It's just that the type of other is ignored, and the type of
>> self always wins. I find tha
On Mon, Dec 26, 2011 at 12:27 AM, Steven D'Aprano
wrote:
> There's nothing in the above that assumes that other has the same type as
> self. It's just that the type of other is ignored, and the type of self
> always wins. I find that a nice, clear rule: x.intersection(y) always
> returns a point w
On Sun, 25 Dec 2011 23:32:41 +1100, Chris Angelico wrote:
> On Sun, Dec 25, 2011 at 11:10 PM, Steven D'Aprano
> wrote:
>> class Point: # An abstract class.
>> def intersect(self, other):
>> blah; blah; blah
>> return Point(x, y) # No, wrong, bad!!! Don't do this.
>>
>> Instead:
On Sun, Dec 25, 2011 at 11:10 PM, Steven D'Aprano
wrote:
> class Point: # An abstract class.
> def intersect(self, other):
> blah; blah; blah
> return Point(x, y) # No, wrong, bad!!! Don't do this.
>
> Instead:
>
> return self.__class__(x, y) # Better.
This would work i
On Sat, 24 Dec 2011 17:24:14 -0800, Rick Johnson wrote:
>> class DrawablePoint( geometry.Point ):
>> class draw( self, ... ):
>> ...
>
> "DrawablePoint"? I suppose there is an "ImaginaryPoint" somewhere in
> this API? Geez
No, but there's an abstract Point, which presumably refers to
On 12/24/2011 6:49 PM, Spencer Pearson wrote:
On Dec 23, 9:13 am, Terry Reedy wrote:
On 12/22/2011 3:21 AM, Spencer Pearson wrote:
I'm writing a geometry package, with Points and Lines and Circles and
so on, and eventually I want to be able to draw these things on the
screen. I have two optio
On Dec 22, 2:21 am, Spencer Pearson wrote:
> I'm writing a geometry package, with Points and Lines and Circles and
> so on, and eventually I want to be able to draw these things on the
> screen.
...which is the main reason for creating a geometry package in the
first place!. I mean, imaginary poi
On Thu, Dec 22, 2011 at 1:21 AM, Spencer Pearson
wrote:
> I see a problem with this, though. The intersection of two lines is
> (usually) an object of type Point. Since DrawableLine inherits from
> Line, this means that unless I redefine the "intersect" method in
> DrawableLine, the intersection o
On Dec 23, 9:13 am, Terry Reedy wrote:
> On 12/22/2011 3:21 AM, Spencer Pearson wrote:
>
> > I'm writing a geometry package, with Points and Lines and Circles and
> > so on, and eventually I want to be able to draw these things on the
> > screen. I have two options so far for how to accomplish thi
On 12/22/2011 3:21 AM, Spencer Pearson wrote:
I'm writing a geometry package, with Points and Lines and Circles and
so on, and eventually I want to be able to draw these things on the
screen. I have two options so far for how to accomplish this, but
neither of them sits quite right with me, and I
14 matches
Mail list logo
