Nos projetos do Django, onde eu sei que pksempre retorna id, prefiro usar idquando ele não entra em conflito com a id()função (em todos os lugares, exceto nomes de variáveis). A razão para isso é que pké uma propriedade 7 vezes mais lenta que ida demora em procurar o pknome do atributo meta.
%timeit obj.id
46 ns ± 0.187 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
%timeit obj.pk
347 ns ± 11.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
Aqui está o código Django relevante:
def _get_pk_val(self, meta=None):
meta = meta or self._meta
return getattr(self, meta.pk.attname)
def _set_pk_val(self, value):
return setattr(self, self._meta.pk.attname, value)
pk = property(_get_pk_val, _set_pk_val)
É realmente um caso raro quando eu preciso usar uma variável chamada pk. Eu prefiro usar algo mais detalhado, como em user_idvez de pk.
Seguir a mesma convenção é preferível em todo o projeto. No seu caso, idexiste um nome de parâmetro, não uma propriedade; portanto, quase não há diferença nos tempos. Os nomes de parâmetros não se chocam com o nome da id()função interna, portanto, é seguro usá-lo idaqui.
Para resumir, cabe a você escolher se deseja usar o nome do campo idou o pkatalho. Se você não está desenvolvendo uma biblioteca para o Django e usa campos automáticos de chave primária para todos os modelos, é seguro usá-lo em idqualquer lugar, o que às vezes é mais rápido. Por outro lado, se você deseja acesso universal a campos de chave primária (provavelmente personalizados), use em pkqualquer lugar. Um terço de microssegundo não é nada para a web.
ide parapk