[Tutor] get name of calling class at runtime

[Serdar Tumgoren]

>> I think it does makes sense to keep SQL confined to well-defined
>> locations. This can be per class - each class holds its own SQL - or a
>> single class that does all database access so all SQL and database
>> dependencies are in one place.

The above is precisely what I'm after, and I agree that the approach I
initially proposed (type-checking the calling class) does have that
bad code smell. I wasn't aware of Mixins -- (well, I'd heard of them
but never really applied the technique). I'll look into that as a
possible solution for logging and other functionality that cuts across
numerous objects (or would decorators be a better approach?). But
meantime, I think inheritance might once again solve my problem:

>
>> class DataSources(object):
>>  def getAdata(self):
>>        # execute sql for callerA
>>  def getBdata(self):
>>        #execute sql for callerB

If I define a root DataSource class as above, and then have all my
committee objects inherit from that, I should have a clean(er),
unified access to my data sources. My only question with that approach
 -- is it generally bad policy to let objects inherit behavior that
they don't need.

For instance, say that I have a parent DataSources class and then I
have subclasses called PresidentCommittee, HouseCommittee,
LeadershipPAC. Now all of these child objects will inherit not only
their own data-retrieval methods, but also the universe of DataSource
methods used by their siblings. Is that generally something to avoid,
or is it an insignificant issue in light of the benefits of
inheritance?