So, instead of adding our new filters to the custom manager, we add them to a custom queryset. But we still want to be able to access them as methods of the manager. We could add stub methods on the manager for each new filter, calling the corresponding method on the queryset - but that would be a blatant DRY violation. A custom __getattr__ method on the manager takes care of that problem.

I tried using this. In ep's approach Manager's init is overriden and it expects an additional argument compared to Django core's Manager. However, in Django code Manager's are called without arguments. So when using object.delete() and object.someothermodel_set.* methods the system tries to call the Manager without arguments and it throws an error. I don't know however, why Django is calling Manager via the Manager model and not thourgh models Manager instance (so it doesn't help if you make argument optional as class can't find the queryset then).. I found ep's approach much too hazard although you could hack it here and there..

This has the added bonus that it only proxies the methods you add in your custom QuerySet class (in the example only the 'upcoming' method). So (for instance) MyModel.objects.delete() fails as it's supposed to.