Python DetailView方法的参数和pk_url_kwarg的用法

我目前正在观看关于Django的课程，并对以下代码感到疑惑：

class RestaurantDetailView(DetailView):
    queryset = Restaurant.objects.all()

    def get_context_data(self, *args, **kwargs):
        context = super().get_context_data(*args, **kwargs)
        return context

    def get_object(self, *args, **kwargs):
        rest_id = self.kwargs.get('rest_id')
        obj = get_object_or_404(Restaurant, id=rest_id)
        return obj

1.）为什么本课程的讲师在

get_context_data

方法中使用

*args

，但在django的源代码中，

get_context_data

只有

**kwargs

2.）此外，还有

get_object

方法。为什么他使用

*args

和

**kwargs

但Django中的方法只有

queryset

参数

3.）还有我的最后一个问题，为什么不使用

pk\u url\u kwarg

变量将

pk

的名称更改为

rest\u id

我重写了这段代码，它仍然有效，但我对Django真的很陌生，我不确定是否误解了什么

class RestaurantDetailView(DetailView):
    pk_url_kwarg = 'rest_id'
    queryset = Restaurant.objects.all()

    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        return context

---

作为Django用户，

def get_context_数据（self，*args，**kwargs）：

和

def get_对象（self，*args，**kwargs）：

在我看来很不寻常。代码将起作用，因为相同的arg和kwarg被传递到

super（）

。您可以争辩说，它使代码更加健壮，因为如果Django在将来的版本中更改签名，它仍然可以工作。但是，我更愿意使用与父类相同的签名

您可以使用

pk\u url\u kwarg

而不是覆盖

get\u对象

，这是正确的。

pk\u url\u kwarg

应该是url模式中kwarg的名称，因此在本例中它应该是

pk\u url\u kwarg='rest\u id'

。

pk\u url\u kwarg

的优点是简化了代码。缺点是，如果您不熟悉Django基于类的视图，那么对象的获取方式就不那么明显

你还可以做一些改变。您可以简单地设置

model

，而不是

queryset=Restaurant.objects.all（）

，因为

get\u queryset

默认为

self.model.objects.all（）

最后，

get\u context\u data

方法除了打印之外什么都不做，所以我会在完成调试后将其完全删除

综合起来，你会得到：

class RestaurantDetailView(DetailView):
    model = Restaurant
    pk_url_kwarg = 'rest_id'