W projektach Django, o których wiem, że pkzawsze zwraca id, wolę używać, idgdy nie koliduje z id()funkcją (wszędzie oprócz nazw zmiennych). Wynika to z tego, że pkjest to właściwość 7 razy wolniejsza niż idczasochłonne wyszukiwanie pknazwy atrybutu 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)
Oto odpowiedni kod Django:
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)
To naprawdę rzadki przypadek, kiedy muszę użyć zmiennej o nazwie pk. Wolę używać czegoś bardziej szczegółowego, jak user_idzamiast pk.
Przestrzeganie tej samej konwencji jest preferowane w całym projekcie. W twoim przypadku idjest to nazwa parametru, a nie właściwość, więc prawie nie ma różnicy w taktowaniu. Nazwy parametrów nie kolidują z nazwą wbudowanej id()funkcji, więc można z niej bezpiecznie korzystać id.
Podsumowując, od Ciebie zależy, czy chcesz użyć nazwy pola, idczy pkskrótu. Jeśli nie tworzysz biblioteki dla Django i używasz automatycznych pól klucza podstawowego dla wszystkich modeli, możesz bezpiecznie używać idwszędzie, co czasami jest szybsze. Z drugiej strony, jeśli chcesz mieć uniwersalny dostęp do (prawdopodobnie niestandardowych) pól klucza głównego, używaj go pkwszędzie. Jedna trzecia mikrosekundy to nic dla sieci.
idi zapk