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

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.

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ą.

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 _...

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.

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

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.

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.