Python Language
Instrukcja pass

Dlaczego miałbyś kiedykolwiek chcieć powiedzieć tłumaczowi, aby wyraźnie nic nie robił? Python ma składniowy wymóg, aby bloki kodu (po if , except def , class itp.) Nie mogły być puste.

Ale czasami pusty blok kodu jest przydatny sam w sobie. Pusty blok class może zdefiniować nową, inną klasę, na przykład wyjątek, który można przechwycić. Pusty blok except może być najprostszym sposobem wyrażenia „prosić o wybaczenie później”, jeśli nie ma o co prosić o wybaczenie. Jeśli iterator wykonuje całe ciężkie podnoszenie, przydatna może być pusta pętla for , aby po prostu uruchomić iterator.

Dlatego jeśli w bloku kodu nic się nie wydarzy, konieczne jest pass , aby taki blok nie wygenerował IndentationError . Alternatywnie można użyć dowolnego wyrażenia (w tym tylko terminu do oceny, takiego jak literał Ellipsis ... lub ciąg, najczęściej docstring), ale pass wyjaśnia, że rzeczywiście nic nie powinno się wydarzyć i nie wymaga do oceny i (przynajmniej tymczasowo) przechowywania w pamięci. Oto niewielka kolekcja z najczęstszymi zastosowaniami pass która przeszła mi przez drogę - wraz z komentarzami na temat dobrych i złych praktyk.

• Ignorowanie (wszystkie lub) pewnego rodzaju Exception (przykład z xml ):

   try:
       self.version = "Expat %d.%d.%d" % expat.version_info
   except AttributeError:
       pass # unknown
  

  Uwaga: Ignorowanie wszystkich typów podwyżek, jak w poniższym przykładzie z pandas , jest ogólnie uważane za złą praktykę, ponieważ wychwytuje również wyjątki, które prawdopodobnie powinny zostać przekazane do dzwoniącego, np. KeyboardInterrupt lub SystemExit (lub nawet HardwareIsOnFireError - Skąd wiesz? nie działa na niestandardowym polu ze zdefiniowanymi konkretnymi błędami, o których niektóre aplikacje dzwoniące chcieliby wiedzieć?).

   try:
       os.unlink(filename_larry)
   except:
       pass
  

  Zamiast tego należy użyć co najmniej except OSError: except Error: lub w tym przypadku najlepiej except OSError: uważa się za dużo lepszą praktykę. Szybka analiza wszystkich modułów Pythona, które zainstalowałem, dała mi do zrozumienia, że ponad 10% wszystkich except ...: pass instrukcje except ...: pass wychwytują wszystkie wyjątki, więc nadal jest to częsty wzorzec w programowaniu w Pythonie.

• Wyprowadzenie klasy wyjątku, która nie dodaje nowego zachowania (np. W scipy ):

   class CompileError(Exception):
       pass
  

  Podobnie, klasy zaprojektowane jako abstrakcyjna klasa podstawowa często mają jawnie puste __init__ lub inne metody, które powinny uzyskać podklasy. (np. pebl )

   class _BaseSubmittingController(_BaseController):
       def submit(self, tasks): pass
       def retrieve(self, deferred_results): pass
  

• Testowanie tego kodu działa poprawnie dla kilku wartości testowych, bez dbania o wyniki (z mpmath ):

   for x, error in MDNewton(mp, f, (1,-2), verbose=0,
                            norm=lambda x: norm(x, inf)):
       pass
  

• W definicjach klas lub funkcji często istnieje już dokumentacja jako obowiązkowa instrukcja, którą należy wykonać jako jedyną w bloku. W takich przypadkach blok może zawierać pass oprócz docstring w celu powiedzenia „To naprawdę nie ma zamiaru nic robić”., Na przykład w pebl :

   class ParsingError(Exception): 
       """Error encountered while parsing an ill-formed datafile."""
       pass
  

• W niektórych przypadkach pass jest używany jako symbol zastępczy, aby powiedzieć „Ta metoda / klasa / if-block / ... nie została jeszcze zaimplementowana, ale to będzie miejsce do zrobienia tego”, chociaż ja osobiście wolę literał Ellipsis ... (UWAGA: tylko python-3) w celu ścisłego rozróżnienia między tym a celowym „brakiem op” w poprzednim przykładzie. Na przykład, jeśli piszę model szerokimi pociągnięciami, mogę pisać

   def update_agent(agent):
       ... 
  

  gdzie inni mogą mieć

   def update_agent(agent):
       pass
  

  przed

   def time_step(agents):
       for agent in agents:
           update_agent(agent)
  

  jako przypomnienie o wypełnieniu funkcji update_agent w późniejszym czasie, ale już teraz uruchom kilka testów, aby sprawdzić, czy reszta kodu zachowuje się zgodnie z przeznaczeniem. (Trzecią opcją dla tego przypadku jest raise NotImplementedError . Jest to przydatne w szczególności w dwóch przypadkach: „Ta abstrakcyjna metoda powinna zostać zaimplementowana przez każdą podklasę, nie ma ogólnego sposobu jej zdefiniowania w tej klasie bazowej” , lub „Ta funkcja o tej nazwie nie jest jeszcze zaimplementowany w tej wersji, ale tak będzie wyglądał jego podpis ” )