Generally there are two schools of thought on this:
- Multiple types with the same name are fine if the name makes sense for them all. Differentiate them via a package/namespace/module etc name.
- Avoid multiple types with the same name as one then has to reply on the package/namespace/module etc name to differentiate them, which can be confusing.
As a general rule, neither of these is "correct" and neither is "wrong". It depends on circumstance. If I provide a library with different implementations of a model, I might choose to call them both
Model, clarifying their difference via different module names, eg
However, what I'd regard as a serious code smell would be to have a base class,
Model and to then add loads of extra features to it via a child class and to still call the latter,
Model too. That's just laziness. You've added to
Model, so give it a name that describes those additions.
And this seems to be what you are describing:
abstract = True
created_at = models.DateTimeField(auto_now_add=True)
updated_at = models.DateTimeField(auto_now=True)
Model with timestamps. So call it something like
TimestampedModel. This avoids confusion over the name and provides a description of the additions.
I've never come across someone reusing the superclass name in their subclasses in this way before. The only benefit I can see to this is it saves putting any effort into coming up with a new name. Sure, naming is hard; but "it's hard" is not an excuse for being lazy.