Jak sprawdzić, czy plik istnieje, używając Pythona, bez użycia instrukcji try?
Teraz dostępny od Pythona 3.4, importuj i tworzymy instancję Pathobiektu o nazwie pliku, i sprawdź is_filemetodę (zauważ, że to zwraca True dla dowiązań symbolicznych wskazujących również na zwykłe pliki):
>>> from pathlib import Path
>>> Path('/').is_file()
False
>>> Path('/initrd.img').is_file()
True
>>> Path('/doesnotexist').is_file()
False
Jeśli korzystasz z Python 2, możesz backportować moduł pathlib z pypi pathlib2lub w inny sposób sprawdzić isfilez os.pathmodułu:
>>> import os
>>> os.path.isfile('/')
False
>>> os.path.isfile('/initrd.img')
True
>>> os.path.isfile('/doesnotexist')
False
Teraz powyższe jest prawdopodobnie najlepszą pragmatyczną bezpośrednią odpowiedzią tutaj, ale istnieje możliwość wyścigu (w zależności od tego, co próbujesz osiągnąć) oraz fakt, że podstawowa implementacja używa try, ale Python używa trywszędzie w swojej implementacji.
Ponieważ Python używa trywszędzie, naprawdę nie ma powodu, aby unikać implementacji, która go używa.
Ale reszta tej odpowiedzi próbuje rozważyć te zastrzeżenia.
Dłuższa, znacznie bardziej pedantyczna odpowiedź
Dostępne od wersji Python 3.4, użyj nowego Pathobiektu w pathlib. Zauważ, że .existsto nie do końca prawda, ponieważ katalogi nie są plikami (z wyjątkiem tego, że w Uniksie wszystko jest plikiem).
>>> from pathlib import Path
>>> root = Path('/')
>>> root.exists()
True
Musimy więc użyć is_file:
>>> root.is_file()
False
Oto pomoc dotycząca is_file:
is_file(self)
Whether this path is a regular file (also True for symlinks pointing
to regular files).
Pobierzmy więc plik, o którym wiemy, że to plik:
>>> import tempfile
>>> file = tempfile.NamedTemporaryFile()
>>> filepathobj = Path(file.name)
>>> filepathobj.is_file()
True
>>> filepathobj.exists()
True
Domyślnie NamedTemporaryFileusuwa plik po zamknięciu (i zostanie automatycznie zamknięty, gdy nie będzie już więcej odwołań do niego).
>>> del file
>>> filepathobj.exists()
False
>>> filepathobj.is_file()
False
Jeśli jednak zagłębisz się w implementację , zobaczysz, że is_fileużywa try:
def is_file(self):
"""
Whether this path is a regular file (also True for symlinks pointing
to regular files).
"""
try:
return S_ISREG(self.stat().st_mode)
except OSError as e:
if e.errno not in (ENOENT, ENOTDIR):
raise
# Path doesn't exist or is a broken symlink
# (see https://bitbucket.org/pitrou/pathlib/issue/12/)
return False
Warunki wyścigu: Dlaczego lubimy próbować
Lubimy to, tryponieważ pozwala uniknąć warunków wyścigowych. Dzięki trypo prostu próbujesz odczytać plik, oczekując, że on tam będzie, a jeśli nie, wychwytujesz wyjątek i wykonujesz dowolne zachowanie rezerwowe, które ma sens.
Jeśli chcesz sprawdzić, czy plik istnieje, zanim spróbujesz go odczytać, być może usuwasz go, a następnie korzystasz z wielu wątków lub procesów lub inny program wie o tym pliku i może go usunąć - ryzykujesz wyścigu sprawdzając istnieje, bo są wtedy wyścigi , aby otworzyć go przed jego stanu (jego istnienie) zmienia.
Warunki wyścigu są bardzo trudne do debugowania, ponieważ istnieje bardzo małe okno, w którym mogą spowodować awarię programu.
Ale jeśli to jest twoja motywacja, to można uzyskać wartość tryrachunku za pomocą suppressmenedżera kontekstowe.
Unikanie warunków wyścigu bez instrukcji try: suppress
Python 3.4 udostępnia nam suppressmenedżera kontekstu (wcześniej ignoremenedżera kontekstu), który robi semantycznie dokładnie to samo w mniejszej liczbie wierszy, a jednocześnie (przynajmniej powierzchownie) spełnia oryginalne zapytanie o uniknięcie tryinstrukcji:
from contextlib import suppress
from pathlib import Path
Stosowanie:
>>> with suppress(OSError), Path('doesnotexist').open() as f:
... for line in f:
... print(line)
...
>>>
>>> with suppress(OSError):
... Path('doesnotexist').unlink()
...
>>>
W przypadku wcześniejszych Pytonów możesz rzucić własne suppress, ale bez nich trybędzie bardziej gadatliwy niż z. Wierzę, że tak naprawdę jest to jedyna odpowiedź, która nie jest używana tryna żadnym poziomie w Pythonie, którą można zastosować przed Pythonem 3.4, ponieważ zamiast tego używa menedżera kontekstu:
class suppress(object):
def __init__(self, *exceptions):
self.exceptions = exceptions
def __enter__(self):
return self
def __exit__(self, exc_type, exc_value, traceback):
if exc_type is not None:
return issubclass(exc_type, self.exceptions)
Być może łatwiejsze z próbą:
from contextlib import contextmanager
@contextmanager
def suppress(*exceptions):
try:
yield
except exceptions:
pass
Inne opcje, które nie spełniają warunku „bez próby”:
plik is
import os
os.path.isfile(path)
z dokumentów :
os.path.isfile(path)
Zwraca wartość True, jeśli ścieżka jest istniejącym zwykłym plikiem. Wynika to dowiązania symboliczne, tak jak islink()i isfile()może być prawdziwe w odniesieniu do tej samej ścieżce.
Ale jeśli zbadasz źródło tej funkcji, zobaczysz, że faktycznie używa instrukcji try:
# This follows symbolic links, so both islink() and isdir() can be true
# for the same path on systems that support symlinks
def isfile(path):
"""Test whether a path is a regular file"""
try:
st = os.stat(path)
except os.error:
return False
return stat.S_ISREG(st.st_mode)
>>> OSError is os.error
True
Wystarczy, że użyje podanej ścieżki, aby sprawdzić, czy może uzyskać statystyki, przechwytuje, OSErrora następnie sprawdza, czy jest to plik, jeśli nie zgłosił wyjątku.
Jeśli zamierzasz coś zrobić z plikiem, sugerowałbym bezpośrednią próbę spróbowania, z wyjątkiem uniknięcia wyścigu:
try:
with open(path) as f:
f.read()
except OSError:
pass
os.access
Dostępny jest dla systemów Unix i Windows os.access, ale aby go użyć, musisz przekazać flagi i nie rozróżnia on plików i katalogów. Jest to bardziej wykorzystywane do testowania, czy rzeczywisty wywołujący użytkownik ma dostęp w środowisku o podwyższonych uprawnieniach:
import os
os.access(path, os.F_OK)
Ma także takie same problemy z wyścigiem jak isfile. Z dokumentów :
Uwaga: Użycie access () do sprawdzenia, czy użytkownik jest upoważniony np. Do otwarcia pliku, zanim faktycznie to zrobi, użycie open () tworzy lukę w zabezpieczeniach, ponieważ użytkownik może wykorzystać krótki odstęp czasu między sprawdzeniem a otwarciem pliku, aby nim manipulować. Lepiej jest stosować techniki EAFP. Na przykład:
if os.access("myfile", os.R_OK):
with open("myfile") as fp:
return fp.read()
return "some default data"
lepiej napisać jako:
try:
fp = open("myfile")
except IOError as e:
if e.errno == errno.EACCES:
return "some default data"
# Not a permission error.
raise
else:
with fp:
return fp.read()
Unikaj używania os.access. Jest to funkcja niskiego poziomu, która ma więcej możliwości wystąpienia błędu użytkownika niż obiekty i funkcje wyższego poziomu omówione powyżej.
Krytyka innej odpowiedzi:
Inna odpowiedź mówi o tym os.access:
Osobiście wolę ten, ponieważ pod maską wywołuje natywne interfejsy API (przez „$ {PYTHON_SRC_DIR} /Modules/posixmodule.c”), ale otwiera także bramę dla możliwych błędów użytkownika i nie jest tak Pythonic jak inne warianty :
Ta odpowiedź mówi, że woli bez skłonności do Pythona, podatna na błędy, bez uzasadnienia. Wygląda na to, że zachęca użytkowników do korzystania z niskopoziomowych interfejsów API bez ich zrozumienia.
Tworzy również menedżera kontekstu, który poprzez bezwarunkowe zwracanie Truepozwala wszystkim wyjątkom (w tym KeyboardInterrupti SystemExit!) Przejść cicho, co jest dobrym sposobem na ukrycie błędów.
Wydaje się, że zachęca to użytkowników do stosowania złych praktyk.
