Kiedy w Pythonie powinienem używać funkcji zamiast metody?

Zen Pythona mówi, że powinien być tylko jeden sposób na zrobienie rzeczy - jednak często spotykam się z problemem decydowania, kiedy użyć funkcji, a kiedy użyć metody.

Weźmy trywialny przykład-obiekt szachownicy. Powiedzmy, że potrzebujemy jakiegoś sposobu, aby uzyskać wszystkie legalne ruchy Króla dostępne na tablicy. Czy piszemy szachownicę?get_king_moves () czy get_king_moves (chess_board)?

Oto kilka powiązanych pytań, na które spojrzałem:

• dlaczego python używa "magicznych metod"?
• czy istnieje powód, dla którego łańcuchy Pythona nie mają metody długości łańcuchów?

Odpowiedzi jakie otrzymałem były w dużej mierze niejednoznaczne:

Dlaczego Python używa metod dla niektórych funkcji (np. list.index()) ale funkcje dla innych(np. len (list))?

Głównym powodem jest historia. Do tych operacji zostały użyte funkcje, które były ogólne dla grupy typów i które były przeznaczone do pracy nawet dla obiekty, które w ogóle nie miały metod (np. krotki). Wygodne jest również posiadanie funkcji, która może łatwo można zastosować do amorficznej kolekcji obiektów, gdy używasz funkcje funkcjonalne Pythona (map (), apply () i in.).

W rzeczywistości implementacja len (), max (), min () jako wbudowanej funkcji jest w rzeczywistości mniej kodem niż implementacja ich jako metod dla każdego typu. Można się spierać o poszczególne przypadki, ale to część Pythona i już za późno na takie fundamentalne zmiany. Funkcje mają aby pozostać, aby uniknąć masowego łamania kodu.

Chociaż interesujące, powyższe nie mówi zbyt wiele o tym, jaką strategię przyjąć.

Jest to jeden z powodów - przy niestandardowych metodach programiści będą możliwość wyboru innej nazwy metody, np. getLength (), length(), getlength() lub w ogóle. Python wymusza ścisłe nazewnictwo, tak aby można użyć wspólnej funkcji len ().

Nieco więcej interesujące. Moim zdaniem funkcje są w pewnym sensie Pythoniczną wersją interfejsów.

Wreszcie, od samego Guido :

rozmowa o możliwościach / interfejsach skłoniła mnie do zastanowienia się nad niektórymi z naszych "rogue" specjalne nazwy metod. W odnośniku językowym jest napisane: "A klasa może zaimplementować pewne operacje, które są wywoływane przez specjalne składni (np. operacje arytmetyczne czy zapisywanie i krojenie) przez definiowanie metod z nazwy specjalne."Ale są wszystkie te metody z nazwami specjalnymi jak __len__ lub __unicode__, które wydają się być przewidziane z korzyścią dla wbudowanych funkcji, a nie dla obsługa składni. Przypuszczalnie w Pythonie opartym na interfejsie, te metody zamieniłyby się w metody o regularnych nazwach na ABC, tak aby __len__ stałoby się

class container:
  ...
  def len(self):
    raise NotImplemented

chociaż, myśląc o tym trochę więcej, nie widzę dlaczego wszystkie składniowe operacje nie tylko wywołują odpowiednia metoda na konkretne ABC. "<", na przykład, prawdopodobnie wywoła "object.lessthan "(a może"comparable.lessthan"). Więc inny korzyścią byłaby możliwość odciągnięcia Pythona od tego mangled-nazwa dziwności, która wydaje mi się ulepszeniem HCI .

Hm. Nie jestem pewien, czy się Zgadzam (rysunek, że: -).

Są dwa bity "uzasadnienia Pythona" , które chciałbym wyjaśnić najpierw.

Po pierwsze, wybrałem len (x) po x. len () z powodów HCI (def __len__() przyszedł znacznie później). Istnieją dwa splecione ze sobą powody, oba HCI:

(a) w przypadku niektórych operacji zapis przedrostkowy czyta się lepiej niż postfix -- prefix (i infix!) działania mają długą tradycję w matematyka, która lubi notacje, gdzie wizualizacje pomagają matematyk myśli o problemie. Porównaj łatwość z jaką my przepisać formułę typu x*(a+b) na x*a + x*b do niezgrabności robienie tego samego przy użyciu surowego OO notacja.

(b) kiedy czytam kod mówiący len(x)i wiem że prosi o długość czegoś. To mówi mi dwie rzeczy: rezultatem jest integer, a argument jest jakimś kontenerem. Wręcz przeciwnie, kiedy czytam x.len(), muszę już wiedzieć, że x jest jakimś kontener implementujący interfejs lub dziedziczący z klasy, która posiada standard len(). Świadkami zamieszania, które czasami mamy, gdy klasa, która nie implementuje odwzorowanie ma get() lub keys() metoda, lub coś, co nie jest plikiem, ma metodę write().

Mówiąc to samo w inny sposób, widzę "len" jako wbudowany operacja . Nie chciałbym tego stracić. Nie mogę powiedzieć na pewno, czy miałeś to na myśli, czy nie, ale 'def len(self): ...'z pewnością brzmi jak ty chcesz go zdegradować do zwykłej metody. Jestem zdecydowanie -1 na tym.

Druga część Pythona, którą obiecałem wyjaśnić, jest powodem dlaczego wybrałem specjalne metody szukania __special__ i nie tylko special. Przewidywałem wiele operacji, które klasy mogą chcieć aby zastąpić, niektóre standardowe (np. __add__ lub __getitem__), niektóre nie tak standard (np. pickle ' s __reduce__ przez długi czas nie miał wsparcia w C kod w ogóle). Nie chciałem, żeby te specjalne operacje używały zwykłych nazwy metod, bo wtedy już istniejące klasy, czyli klasy napisane przez użytkownicy bez pamięci encyklopedycznej dla wszystkich metod specjalnych, będzie narażony na przypadkowe definiować operacje, których nie chcieli wdrożenie, co może mieć katastrofalne konsekwencje. Ivan Krstić wyjaśnił to bardziej zwięźle w swojej wiadomości, która dotarła po tym, jak spisałem to wszystko.

-- --Guido van Rossum (Strona domowa: http://www.python.org ~ guido/)

Rozumiem to, że w niektórych przypadkach zapis przedrostkowy ma po prostu większy sens(tj.Kwak ma więcej sensu niż Kwak(kaczka) z językowego punktu widzenia.) i ponownie funkcje pozwalają na "Interfejsy".

W takim przypadku moim zdaniem implementacja get_king_moves opierałaby się wyłącznie na pierwszym punkcie Guido. Ale to wciąż pozostawia wiele otwartych pytań dotyczących powiedzmy, implementacji klasy stosu i kolejki z podobnymi metodami push i pop - czy powinny to być Funkcje czy metody? (tutaj domyślam się funkcji, ponieważ naprawdę chcę zasygnalizować interfejs push-pop)

TLDR: Czy ktos moze wyjasnic jaka jest strategia decydowania kiedy uzywac funkcji vs. metody powinny być?