3 ms·

But my problem is that most people wouldn't even think of subclassing QuerySet. When we write methods that operate on collections of things, we typically use @

But my problem is that most people wouldn't even think of subclassing QuerySet. When we write methods that operate on collections of things, we typically use @classmethod. Without @classmethod, we'd have to write a custom metaclass (and instruct our class to use that) if we wanted even a single class method on a class. Multiple inheritance would break (or at least be difficult to reason about) when classes defined class methods, because there would have to be both an instance method resolution order and a class MRO. Fortunately Python's built-in `type` provides the descriptor protocol, which allows us to have class methods and instance methods and properties and all these other nice things without having to metaprogram or hack the interpreter. All I'm asking for is a similar (if less ornate) interface for Django models, wherein the methods that operate on collections of things can be defined alongside the methods that operate on individual things, without requiring a knowledge of Manager/QuerySet internals.

j4mie 14y ago
> But my problem is that most people wouldn't even think of subclassing QuerySet. I'd argue that's a documentation issue. QuerySet is Django's abstraction of a set of filterable database results. Keeping this conceptually separate from other parts of the ORM, such as the model class, is valuable IMO, and I'm not sure we gain much by trying to hide the details. One of the things I love about Django's philosophy is that it generally provides shortcuts that encapsulate common patterns without obscuring them. There's a fine line between discussing the minutiae of API design and bikeshedding, and I think that anything Django can do to help here is valuable, so I won't push the issue any further. Let's pick it up again on the mailing list or Trac at an appropriate time.
simonw 14y ago
A few years ago I was experimenting with exactly this problem, and I came up with an API that worked using an inner class on the model. I can't find the code now, but from memory it looked something like this: class BlogEntry(models.Model, MagicManagerMixin): title = models.CharField(max_length = 128) is_published = models.BooleanField(default = False) class QuerySet(models.QuerySet): def published(self): return self.filter(is_published = True) entries = BlogEntry.objects.published() Where MagicManagerMixin was some scary code that made sure the objects Manager would use the queryset subclass.

j4mie 14y ago

> But my problem is that most people wouldn't even think of subclassing QuerySet. I'd argue that's a documentation issue. QuerySet is Django's abstraction of a set of filterable database results. Keeping this conceptually separate from other parts of the ORM, such as the model class, is valuable IMO, and I'm not sure we gain much by trying to hide the details. One of the things I love about Django's philosophy is that it generally provides shortcuts that encapsulate common patterns without obscuring them. There's a fine line between discussing the minutiae of API design and bikeshedding, and I think that anything Django can do to help here is valuable, so I won't push the issue any further. Let's pick it up again on the mailing list or Trac at an appropriate time.

simonw 14y ago

A few years ago I was experimenting with exactly this problem, and I came up with an API that worked using an inner class on the model. I can't find the code now, but from memory it looked something like this: class BlogEntry(models.Model, MagicManagerMixin): title = models.CharField(max_length = 128) is_published = models.BooleanField(default = False) class QuerySet(models.QuerySet): def published(self): return self.filter(is_published = True) entries = BlogEntry.objects.published() Where MagicManagerMixin was some scary code that made sure the objects Manager would use the queryset subclass.