On Dec 25 2011, 2:58 pm, Terry Reedy <tjre...@udel.edu> wrote: > On 12/24/2011 6:49 PM,SpencerPearsonwrote: > > > On Dec 23, 9:13 am, Terry Reedy<tjre...@udel.edu> 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 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'd like the opinion of > >>> comp.lang.python's wizened elders. > > >>> Option 1. Subclassing. > >>> The most Pythonic way would seem to be writing subclasses for the > >>> things I want to display, adding a ".draw(...)" method to each one, > >>> like this: > > There are people who would advocate a Drawable base class with a virtual > or abstract .draw method and that DrawablePoint, etc, inherit from > Drawable and Point. > > >>> Option 2. A "draw" function, with a function dictionary. > > >> Option 3? Add a draw method to existing classes, rather than subclassing? > > Thanks for the response! Do you mean something like this? > > class Point(GeometricObject): > > def intersect(self, other): > > ... > > I am interpreting this to mean that you have a world coordinate system > for instances that have location and size. > > > def union(self, other): > > ... > > def draw(self, ...): > > ... > > Yes. I would consider that Option 0, the default, unless you have good > reason to choose another. I would certainly include it on a list of options. > > > I'd like to avoid this, because... well, what I want is a geometry > > package, and it seems to me that whistles and bells like GUI support > > ought to be confined to subpackages. I'd look at this and think, "the > > rest of the Point class deals with fundamental geometric reality. > > What's this GUI method doing mixed in with my beautiful mathematical > > purity?" > > By default, all Python objects have a text representation method. I do > not see that giving all concrete geometric objects (with a location and > size) a visual representation is much different. I would use drawing > functions that accept the coordinates and distances of your geometry > world and translate to low-level pixel functions for a particular gui > system. I agree that your geometrical objects should not know about > pixels, screens, windows, and aspect ratios. > > > Is this the wrong attitude to take? > > It depends on *your* goal and values. > > > Or did you mean this? > > In file "geometry/gui.py": > > def draw_point(point, ...): > > ... > > Point.draw = draw_point > > > I've never modified an existing class before, and I fear the > > unfamiliar. If that's what you meant... it's really an acceptable > > thing to do? > > Yes, in my opinion. The advantage of this is putting all the draw > methods together, and possibly having more than one one set. On the > other hand, one needs to know the data attributes of each class to > understand its draw method. > > > It seems like somebody might see "some_point.draw(...)" > > and be confused by the method's absence in the Point class definition. > > With either suboption, you should put an abstract .draw method in the > GeometricObject base class. > > I would look at various game, graph, geometry, and gui packages handle > drawing for more ideas. > > -- > Terry Jan Reedy
(I'm sorry for my delayed response -- I've been travelling and not had reliable Internet access.) On 2011-12-25, Terry Reedy <tjre...@udel.edu> wrote: > There are people who would advocate a Drawable base class with a virtual > or abstract .draw method and that DrawablePoint, etc, inherit from > Drawable and Point. Yes... yes, that makes sense to me. > By default, all Python objects have a text representation method. I do > not see that giving all concrete geometric objects (with a location and > size) a visual representation is much different. I would use drawing > functions that accept the coordinates and distances of your geometry > world and translate to low-level pixel functions for a particular gui > system. I agree that your geometrical objects should not know about > pixels, screens, windows, and aspect ratios. Ha! Oh, I've been being silly. I was going to claim that since there is no standard Python GUI, I ought not chain myself to any one of the candidates. Then I learned that Tkinter comes standard with Python. Oops. All right, now that I know that, the comparison to having a text representation seems very reasonable. I'll definitely reconsider making the draw() method a requirement for all GeometricObjects. >> I've never modified an existing class before, and I fear the >> unfamiliar. If that's what you meant... it's really an acceptable >> thing to do? > > Yes, in my opinion. The advantage of this is putting all the draw > methods together, and possibly having more than one one set. On the > other hand, one needs to know the data attributes of each class to > understand its draw method. > >> It seems like somebody might see "some_point.draw(...)" >> and be confused by the method's absence in the Point class definition. > > With either suboption, you should put an abstract .draw method in the > GeometricObject base class. Sure, sure. I'm comfortable with this way of doing things now. Thanks so much for all your help! -Spencer -- http://mail.python.org/mailman/listinfo/python-list
