Co w Pythonie oznacza „stosowanie zasady EAFP”? Czy mógłbyś podać jakieś przykłady?
Co w Pythonie oznacza „stosowanie zasady EAFP”? Czy mógłbyś podać jakieś przykłady?
Odpowiedzi:
Ze słownika :
Łatwiej prosić o przebaczenie niż o pozwolenie. Ten wspólny styl kodowania w Pythonie zakłada istnienie prawidłowych kluczy lub atrybutów i wyłapuje wyjątki, jeśli założenie okaże się fałszywe. Ten czysty i szybki styl charakteryzuje się obecnością wielu
try
iexcept
wypowiedzi. Technika kontrastuje ze stylem LBYL wspólnym dla wielu innych języków, takich jak C.
Przykładem może być próba uzyskania dostępu do klucza słownika.
EAFP:
try:
x = my_dict["key"]
except KeyError:
# handle missing key
LBYL:
if "key" in my_dict:
x = my_dict["key"]
else:
# handle missing key
Wersja LBYL musi dwukrotnie przeszukiwać klucz w słowniku i może zostać uznana za nieco mniej czytelną.
x
gdy klucz nie istnieje: x = mydict.get('key')
zwróci, None
jeśli 'key'
nie ma my_dict
; możesz też zrobić .get('key', <something>)
, a wtedy x zostanie przypisane to coś, jeśli klucza nie ma w słowniku. dict.setdefault()
i collections.defaultdict
są również fajne do unikania nadmiaru kodu.
except KeyError
równie dobrze AttributeError
są proste, ale niektóre z najgorszych przykładów. Tak wiele razy utknąłem w debugowaniu czegoś, ponieważ except AttributeError
zostało umieszczone w niewłaściwym miejscu, co kończyło się wyłapaniem błędu niewłaściwego atrybutu, podniesionego głębiej w łańcuchu. Lepsze przykłady myślę to: try: open() ... except: IOError
. Lubtry: parseLine() ... except ParseError
Spróbuję to wyjaśnić na innym przykładzie.
Tutaj próbujemy uzyskać dostęp do pliku i wydrukować zawartość w konsoli.
Możemy chcieć sprawdzić, czy możemy uzyskać dostęp do pliku, a jeśli to możliwe, otworzymy go i wydrukujemy zawartość. Jeśli nie możemy uzyskać dostępu do pliku, trafimy w tę else
część. Powodem, dla którego jest to stan wyścigu, jest to, że najpierw wykonujemy kontrolę dostępu. Zanim dotrzemy, with open(my_file) as f:
być może nie możemy już uzyskać do niego dostępu z powodu pewnych problemów z uprawnieniami (na przykład inny proces uzyskuje wyłączną blokadę pliku). Ten kod prawdopodobnie zgłosi błąd i nie będziemy w stanie wychwycić tego błędu, ponieważ myśleliśmy, że możemy uzyskać dostęp do pliku.
import os
my_file = "/path/to/my/file.txt"
# Race condition
if os.access(my_file, os.R_OK):
with open(my_file) as f:
print(f.read())
else:
print("File can't be accessed")
W tym przykładzie po prostu próbujemy otworzyć plik i jeśli nie możemy go otworzyć, wyrzuci plik IOError
. Jeśli możemy, otworzymy plik i wydrukujemy zawartość. Więc zamiast o coś pytać , próbujemy to zrobić. Jeśli to zadziała, świetnie! Jeśli tak się nie stanie, wychwycimy błąd i zajmiemy się nim.
# # No race condition
try:
f = open(my_file)
except IOError as e:
print("File can't be accessed")
else:
with f:
print(f.read())
Nazywam to „optymistycznym programowaniem”. Chodzi o to, że w większości przypadków ludzie postąpią właściwie, a błędów powinno być niewiele. Dlatego najpierw zakoduj, aby wydarzyło się „właściwe rozwiązanie”, a następnie wyłap błędy, jeśli tak się nie stanie.
Mam wrażenie, że jeśli użytkownik będzie popełniał błędy, to on powinien ponosić konsekwencje czasowe. Ludzie, którzy używają tego narzędzia we właściwy sposób, są przyspieszani.