From: Brian M. <br...@gr...> - 2009-07-09 04:12:23
|
Gerald, > I've been working on adding iter_... > methods to complement the > existing get_... methods in the proxy database > classes. For example, > living.py defines get_person_handles, so I'm adding > iter_person_handles. As I'm looking at the other > objects, I'm trying > to reduce some duplication and (being the lazy guy that I > am) some > work. I see that some methods are repeated verbatim > between > filter.py, living.py, referenced.py and private.py. > For example, > get_place_handles is the same in filter.py and living.py; > get_researcher is the same in all four. > > I'd like to propose (and do the work) enhancing > proxybase.py to > implement basic versions of these common routines, which > then can be > overridden as needed in the derived classes. This > will reduce > duplication and hopefully increase maintainability. > Please let me > know if you agree with this approach. > > PS Using this approach will make my other work easier since > I may only > have to define iter... in the derived classes. > Proxybase would then > contain methods like: > > def get_person_handles(...) > return > list(self.iter_person_handles(...)) There is only one thing I don't like about Python: it lacks static typing. I have a very good understanding of the advantages and disadvantages of static typing vs. dynamic typing (if it quacks like a duck, etc.). I think dynamic typing has its place in small, simple programs. It can even be great for larger programs if the developers are strongly committed to writing unit tests. But it is my strong opinion that dynamic typing is inappropriate for large, complex, dynamic software products like Gramps. Especially considering our poor record for writing and maintaining unit tests. Because of my strong feelings about type checking, I generally try to apply static typing techniques in Gramps. For example, in the proxybase, I guided the decision to make many of the functions raise NotImplementedError. I did this to emulate a pure virtual method and to essentially make proxybase an abstract class. As I see it, this *increases* maintainability because it increases the likelihood that if someone adds a method they won't forget to add it to all the subclasses. In other words, it enforces the interface to some degree. I can see your perspective that it will be easier *for you* to only implement the function once. But I would argue that it will be easier for *other people* to understand later and it will be easier *for everyone* to debug if you follow the existing paradigm. I understand completely that my perspective is not "pythonic". I'm sure my words are considered Python heresy in some circles. I'm OK with that. Feel free to call me a Python weenie. But I just wanted to express my perspective. Now that I feel I have been heard, you have my blessing to do whatever you think is best. Thanks for all your hard work. ~Brian |