Czytelność kodu Pythona naukowego (kontynuacje linii, nazwy zmiennych, import)

Question

Czy najlepsze praktyki stylistyczne Pythona mają zastosowanie do kodowania naukowego?

Trudno jest utrzymać czytelność kodu w języku Python.

Na przykład sugerowane jest używanie znaczących nazw zmiennych i utrzymywanie porządku nazw przez unikanie import *. Tak więc np. :

import numpy as np 
    normbar = np.random.normal(mean, std, np.shape(foo)) 

Ale te sugestie mogą prowadzić do trudnego do odczytania kodu, szczególnie biorąc pod uwagę szerokość linii o długości 79 znaków. Na przykład, po prostu napisał następującą operację:

net["weights"][ix1][ix2] += lrate * (CD/nCases - opts["weightcost_pretrain"].dot(net["weights"][ix1][ix2])) 

mogę span ekspresję całej linii:

net["weights"][ix1][ix2] += lrate * (CD/nCases - 
    opts["weightcost_pretrain"].dot(net["weights"][ix1][ix2])) 

ale to nie wydaje się znacznie lepiej, i nie jestem pewien, jak głęboko, aby wciąć druga linia. Tego rodzaju kontynuacje linii stają się jeszcze trudniejsze, gdy jeden z nich jest wcięty w pętlę zagnieżdżoną, a na linii jest tylko 50 znaków.

Czy powinienem zaakceptować, że naukowy Python wygląda niezgrabnie, czy też są sposoby na uniknięcie linii, jak w powyższym przykładzie?

Niektóre potencjalne podejścia są:

• stosując krótsze nazwy zmiennych
• stosując krótsze słownika nazwy klawiszy
• importowanie funkcji NumPy bezpośrednio i przypisywanie im krótkich nazw
• definiujące funkcje pomocnicze dla kombinacji operacji arytmetycznych
• dzielenie operacji na mniejsze części i umieszczanie po jednym w każdej linii

Byłbym wdzięczny za wszelkie mądrości, które z nich należy realizować, a których unikać, a także sugestie dotyczące innych środków zaradczych.

Answer 1

• definiowania funkcji pomocniczych dla kombinacji operacji arytmetycznych
• operacje załamujące się na mniejsze kawałki i umieszczenie na każdej linii

Są to zarówno dobre pomysły-w zgodzie z zamiarem za PEP 8 i ogólnie w stylu Pythonic. W rzeczywistości, ilekroć ktoś sugeruje modyfikowanie PEP 8, aby uzyskać więcej informacji na temat długich linii, połowa odpowiedzi to zazwyczaj "Jeśli przekroczysz limit linii, prawdopodobnie za dużo robisz w jednym wyrażeniu".

Co ważniejsze, faktorowanie kodu i podawanie rozsądnych nazw rozsądnym operacjom zawsze jest dobrym pomysłem.

Oczywiście, nie wiedząc dokładnie, co wszystkie te rzeczy oznaczają, mogę się tylko domyślać, jak podzielić je, ale myślę, że coś takiego byłoby dość czytelne i sensowne:

cost = opts["weightcost_pretrain"].dot(net["weights"][ix1][ix2]) 
weight = lrate * (CD/nCases - cost) 
net["weights"][ix1][ix2] += weight 

Answer 2

myślę styl przewodnik zawsze stosuje się - codziennie używam Pythona do pracy naukowej i odkrywam, że jestem w stanie łatwiej odczytać mój kod i wrócić do niego kilka miesięcy później przy niewielkim wysiłku, jeśli podzieliłem długie wiersze na logiczne komponenty i sensowne nazwy zmiennych, lub użył funkcji.

zrobiłbym czegoś więcej tak:

weights = net["weights"][ix1][ix2] 
opts_arr = opts["weightcost_pretrain"] 
weights += lrate * (CD/nCases - opts_arr.dot(weights)) 

Innym sposobem na powiedzenie, że Python jest „zwięzłe” jest to, że Python jest składniowo gęsty, i uważam, że to trudniejsze do odczytania i zrozumienia długą linię Python niż długa linia Javy (szczególnie przy korzystaniu z wysokopoziomowych funkcji z bibliotek stron trzecich, które ukrywają logikę niskiego poziomu, np. NumPy).