On Tue, Oct 6, 2009 at 2:26 PM, Serdar Tumgoren <zstumgo...@gmail.com> wrote:
> I have a set of classes that I've named models.py (following the > Django convention, though it's not technically a Django project or > app). > > Inside that file, I had initially grouped together a number of > classes, subclasses and mixin classes. I've broken out the mixins into > a separate file and am now importing those as a module, which has > helped tame models.py quite a bit. Now I'm left with a number of > subclasses that add in certain functionalities that are not central to > the models themselves. > > For instance, I have a class called FilingsParser and then a > FilingsParserAuto subclass which just triggers methods on the > FilingsParser when an instance is created: > > class FilingsParserAuto(FilingsParser): > > That subclass is the one I'm using in a separate program that relies > on the "autofire" behavior. I have a number of these Auto subclasses > and it's resulted in a bit of bloat inside models.py. > > So to finally ask the question -- would the above subclasses be better > defined as part of the program that requires the "auto" behavior? Or > is it preferable to create some sort of API or Auto module where these > sublasses live? I don't think there is a "right" answer to this question. It depends on how the classes are used and related to each other. If the Auto classes are related or if they are useful to more than one client, perhaps you should make an auto_models.py to hold them. If they are only useful to individual projects you might include each one with its client. Kent _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
