如果在计算can_delete()时使用Q对象会怎么样？
例如，将can_delete()更改为：

@property
    def can_delete(self)
        return X.objects \
            .annotate(can_delete_qs=ExpressionWrapper(Q(a=True, b__c=True, c__in=ALLOWED_STATES,...) & ~Q(d=5), output_field=models.BooleanField()) \
            .get(id=self.id) \
            .can_delete_qs

警告：未经测试的代码。
这样做的代价是，现在每次调用can_delete()都需要调用一次数据库，即使内存中有对象。然而，由于您已经有了一种使用annotate为整个查询集计算this的方法，因此您每次只会为单个对象调用this，这并不坏。
这样做的好处是，您可以在两个地方使用相同的Q表达式。

您可以检查对象的属性内的can_delete注解：

def can_delete(self)
     if hasattr( self, 'can_delete_qs'):  # was this object annotated?
         return self.can_delete_qs        # if so return the annotation value
     # this goes on for 6 and clause
     return self.a and self.b.c and ...   # as before

如果前面的查询已经获得了信息，这将避免不必要的DB调用。
但是要注意，当您引用obj.can_delete时，引起注解的信息可能已经在DB中更改了。如果这是可能的，并且删除数据库中现在评估为can_delete_qs = False的内容的后果是严重的，那么您不应该缓存此信息，而是每次都使用数据库查询重新评估它。
为了维护性而不是效率，请删除Python评估，并使用Nico奥德尔的建议替换其余属性。此外，在一个地方（DRY）定义Q对象，并将其导入到任何需要的地方

CAN_DELETE_Q = Q(a=True, b__c=True, c__in=ALLOWED_STATES,...) & ~Q(d=5)

from wherever import CAN_DELETE_Q

...
    .annotate(can_delete_qs=ExpressionWrapper( CAN_DELETE_Q) ...

我不知道的是，你是否可以在Django完全初始化数据库之前定义一个Q表达式。如果没有，你需要一个动态导入或一个惰性评估来延迟评估，直到Django启动并运行之后。