Nos projetos do Django, onde eu sei que pk
sempre retorna id
, prefiro usar id
quando 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 id
a demora em procurar o pk
nome 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_id
vez de pk
.
Seguir a mesma convenção é preferível em todo o projeto. No seu caso, id
existe 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 id
aqui.
Para resumir, cabe a você escolher se deseja usar o nome do campo id
ou o pk
atalho. 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 id
qualquer 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 pk
qualquer lugar. Um terço de microssegundo não é nada para a web.
id
e parapk