Uzgodnione z @jolvi, @ArundasR i innymi, ostrzeżenie pojawia się w przypadku funkcji członkowskiej, która nie używa self
.
Jeśli jesteś pewien, że PyCharm się myli, że funkcja nie powinna być a @staticmethod
, a jeśli cenisz zero ostrzeżeń, możesz to zrobić na dwa różne sposoby:
Obejście nr 1
def bar(self):
self.is_not_used()
doing_something_without_self()
def is_not_used(self):
pass
Obejście nr 2 [Thanks @ DavidPärsson ]
# noinspection PyMethodMayBeStatic
def bar(self):
doing_something_without_self()
Aplikacja, którą miałem w tym celu (powód, dla którego nie mogłem użyć @staticmethod), polegała na tworzeniu tabeli funkcji obsługi odpowiadających na pole podtypu protokołu. Wszyscy przewodnicy musieli oczywiście mieć tę samą formę (statyczną lub niestatyczną). Ale niektórzy nie zrobili nic z instancją. Gdybym uczynił te statyczne, dostałbym "TypeError: 'staticmethod' object is not callable".
Na poparcie konsternacji PO, sugerowanie dodawania metody statycznej, kiedy tylko jest to możliwe, jest sprzeczne z tą zasadą , że łatwiej jest uczynić kod mniej restrykcyjnym później, niż uczynić go bardziej - uczynienie metody statyczną czyni ją mniej restrykcyjną teraz, ponieważ można wywołaj class.f () zamiast instance.f ().
Zgadnij, dlaczego istnieje to ostrzeżenie:
- To reklamuje staticmethod . Uświadamia programistom coś, co mogli zamienić.
- Jak wskazuje @ JohnWorrall's, przyciąga twoją uwagę, gdy jaźń została nieumyślnie pominięta w funkcji.
- Jest to wskazówka do ponownego przemyślenia modelu obiektowego; może funkcja w ogóle nie należy do tej klasy.
self
gdzieś w metodzie? (Jeśli pytanie naprawdę brzmi "dlaczego projektanci PyCharm zaprojektowali to w ten sposób ... będziesz musiał ich zapytać, a nie SO ...)