PEP 8, dlaczego nie ma spacji wokół '=' w argumencie słowa kluczowego lub domyślnej wartości parametru?


103

Dlaczego PEP 8 nie zaleca stosowania spacji =w argumencie słowa kluczowego lub domyślnej wartości parametru ?

Czy jest to niezgodne z zalecaniem spacji wokół każdego innego wystąpienia =w kodzie Pythona?

Jak jest:

func(1, 2, very_long_variable_name=another_very_long_variable_name)

lepszy niż:

func(1, 2, very_long_variable_name = another_very_long_variable_name)

Wszelkie linki do dyskusji / wyjaśnień BDFL Pythona będą mile widziane.

Pamiętaj, to pytanie dotyczy bardziej kwargs niż wartości domyślnych, właśnie użyłem wyrażenia z PEP 8.

Nie szukam opinii. Pytam o powody tej decyzji. To bardziej przypomina pytanie, dlaczego miałbym używać {w tym samym wierszu, co ifinstrukcja w programie C, a nie, czy powinienem go używać, czy nie.

Odpowiedzi:


72

Myślę, że dzieje się tak dlatego, że argument słowa kluczowego zasadniczo różni się od przypisania zmiennej.

Na przykład jest mnóstwo takiego kodu:

kw1 = some_value
kw2 = some_value
kw3 = some_value
some_func(
    1,
    2,
    kw1=kw1,
    kw2=kw2,
    kw3=kw3)

Jak widzisz, przypisanie zmiennej do argumentu słowa kluczowego o dokładnie takiej samej nazwie ma całkowity sens, więc widzenie ich bez spacji jest bardziej czytelne. Łatwiej jest rozpoznać, że używamy argumentów słów kluczowych i nie przypisujemy sobie zmiennej.

Ponadto parametry zwykle mieszczą się w tej samej linii, podczas gdy przydziały zwykle znajdują się w osobnym wierszu, więc oszczędność miejsca może być tam ważną kwestią.


6
może tak być, ale nadal wydaje się dziwne wprowadzenie tej ikony IMO w zaleceniach dotyczących stylu kodu dla tak dobrze zaprojektowanego języka, tylko po to, aby zaoszczędzić 2 znaki. To tak, jakby styl kodu java mówił, że lepiej jest wstawić {nowy wiersz po if(zapisuje tę samą liczbę znaków), ale nie w definicji klasy. Również parametr słowa kluczowego różni się od wartości domyślnej, ale nadal używa tego samego zalecenia dotyczącego stylu.
soulcheck

3
Jak powiedziałem, są to różne rzeczy. Warto napisać je inaczej.
fortran

6
powiedziałbym, że nie jest bardziej czytelny niż kw1 = kw1, kw2 = kw2;), ale może tak myśleli Guido i Barry.
soulcheck

1
Przyjmuję tę odpowiedź, ponieważ jest całkiem przekonująca. nie miałbym nic przeciwko
linkowi

5
Fakt, że argument słowa kluczowego zasadniczo różni się od przypisania zmiennej, nie jest ważnym argumentem za różnymi konwencjami IMO, ponieważ różnica jest już jasna z kontekstu. Pierwsza zachodzi w wywołaniu funkcji, a druga musi działać samodzielnie na bieżącym poziomie wcięcia. IMO, dla nazw zmiennych dłuższych niż 5-6 znaków (czyli w przypadku większości rzeczywistych), wariant ze spacjami jest zdecydowanie bardziej czytelny.
Axel,

13

Nie użyłbym argumentu very_long_variable_name jako domyślnego. Więc rozważ to:

func(1, 2, axis='x', angle=90, size=450, name='foo bar')

Nad tym:

func(1, 2, axis = 'x', angle = 90, size = 450, name = 'foo bar')

Nie ma też większego sensu używanie zmiennych jako wartości domyślnych. Być może jakieś stałe zmienne (które tak naprawdę nie są stałymi) iw takim przypadku użyłbym nazw, które są same wielkie litery, opisowe, ale jak najkrótsze. Więc nie ma innego_bardzo _...


1
to są argumenty słów kluczowych, podobny przykład jest w PEP i tylko
sprawiłem,

3
Mówisz (zasadniczo): aby zasada braku spacji była sensowna, napisz bardzo krótkie nazwy zmiennych. Ale JEŚLI ma się długie nazwy zmiennych, wówczas reguła braku spacji tworzy zagracone środowisko. Argument, że `` to nie jest zadanie, więc to różne rzeczy '', mi nie odpowiada, ponieważ bardziej zależy mi na czytelności niż na semantyce, a jeśli nie jest to `` domyślna wartość zadania '', to co jest to?
PatrickT

1
@PatrickT Argument „to nie jest zadanie, więc są to różne rzeczy” nie wyjaśnia, dlaczego tak jest (pojęcie filozoficzne); Wyjaśnia jedynie, dlaczego tak jest (pojęcie syntaktyczne).
Mateen Ulhaq

11

Są wady i zalety.

Bardzo nie podoba mi się sposób odczytu kodu zgodnego z PEP8. Nie wierzę w argument, który very_long_variable_name=another_very_long_variable_namemoże być bardziej czytelny dla człowieka niż very_long_variable_name = another_very_long_variable_name. Nie tak czytają ludzie. Jest to dodatkowe obciążenie poznawcze, szczególnie przy braku podświetlania składni.

Istnieje jednak znacząca korzyść. Przestrzeganie zasad odstępów sprawia, że ​​wyszukiwanie parametrów wyłącznie przy użyciu narzędzi jest znacznie bardziej efektywne.


Cóż, jeśli będziesz przestrzegać spacji wokół =, wyszukiwanie za pomocą narzędzi nie powinno być inne.
NoName

10

IMO pomijając spacje dla argumentów zapewnia czystsze wizualne grupowanie par arg / wartość; wygląda na mniej zagracony.


Generalnie lubię spacje, więc staram się umieszczać spacje również w nawiasach, więc wszystkie parametry są otoczone spacją. Ale myślę, że arg1=40jest bardziej czytelny, ponieważ związek jest bardziej oczywisty.
Charlie Gorichanaz

3

Myślę, że jest tego kilka powodów, chociaż mogę tylko racjonalizować:

  1. Oszczędza miejsce, pozwalając więcej definicji funkcji i wywołań zmieścić się w jednej linii i oszczędzając więcej miejsca na same nazwy argumentów.
  2. Łącząc każde słowo kluczowe i wartość, możesz łatwiej oddzielić różne argumenty spacją po przecinku. Oznacza to, że możesz szybko sprawdzić, ile argumentów podałeś.
  3. Składnia różni się wówczas od przypisań zmiennych, które mogą mieć taką samą nazwę.
  4. Ponadto składnia różni się (jeszcze bardziej) od sprawdzania równości, a == bktóre mogą być również prawidłowymi wyrażeniami w wywołaniu.

3

Dla mnie sprawia, że ​​kod jest bardziej czytelny i dlatego jest dobrą konwencją.

Myślę, że kluczowa różnica pod względem stylu między przypisaniami zmiennych a przypisaniami słów kluczowych funkcji polega na tym, że =w wierszu powinno znajdować się tylko jedno słowo dla pierwszego, podczas gdy ogólnie =w wierszu znajduje się wiele znaków dla drugiego.

Jeśli nie wystąpiły inne względy, wolelibyśmy foo = 42się foo=42, ponieważ ten ostatni nie jest jak równy znaki zazwyczaj sformatowana, a ponieważ były ładnie wizualnie oddziela zmiennej i wartość ze spacjami.

Ale gdy istnieje wiele zadania na jednej linii, wolimy f(foo=42, bar=43, baz=44)się f(foo = 42, bar = 43, baz = 44), ponieważ były wizualnie oddziela kilka zadań z spacji, natomiast drugi nie, co czyni go nieco trudniej zobaczyć, gdzie pary kluczowe / wartość są.

Ujmę to inaczej: za konwencją stoi konsekwencja. Ta spójność jest następująca: „najwyższy poziom separacji” jest wizualnie wyraźniejszy dzięki przestrzeniom. Żadne niższe poziomy separacji nie są (ponieważ byłoby to pomylone z białymi znakami oddzielającymi wyższy poziom). W przypadku przypisywania zmiennych najwyższy poziom separacji występuje między zmienną a wartością. W przypadku przypisania słów kluczowych funkcji najwyższy poziom separacji występuje między samymi przypisaniami.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.