A side effect of this question is that I was lead to this post, which states:
Whenever isinstance is used, control flow forks; one type of object goes dow
isinstance
, since Python 2.6, has become quite nice as long as you follow the "key rule of good design" as explained in the classic "gang of 4" book: design to an interface, not to an implementation. Specifically, 2.6's new Abstract Base Classes are the only things you should be using for isinstance
and issubclass
checks, not concrete "implementation" types.
Unfortunately there is no abstract class in 2.6's standard library to summarize the concept of "this number is Integral", but you can make one such ABC by checking whether the class has a special method __index__
(don't use __int__
, which is also supplied by such definitely non-integral classes as float
and str
-- __index__
was introduced specifically to assert "instances of this class can be made into integers with no loss of important information") and use isinstance
on that "interface" (abstract base class) rather than the specific implementation int
, which is way too restrictive.
You could also make an ABC summarizing the concept of "having m, h and s attributes" (might be useful to accept attribute synonyms so as to tolerate a datetime.time
or maybe timedelta
instance, for example -- not sure whether you're representing an instant or a lapse of time with your MyTime
class, the name suggests the former but the existence of addition suggests the latter), again to avoid the very restrictive implications of isinstance
with a concrete implementation cass.