Python Language
Заявление о прохождении

Зачем вам когда-либо хотеть сказать переводчику явно ничего не делать? Python имеет синтаксическое требование, чтобы блоки кода (после if , except , def , class и т. Д.) Не могут быть пустыми.

Но иногда пустой блок кода полезен сам по себе. Пустой блок class может определять новый, другой класс, например исключение, которое можно поймать. Пустым except блока может быть самый простой способ выразить «просить прощения позже», если нечего просить прощения. Если итератор делает всю тяжелую работу, пустой for цикла , чтобы просто запустить итератор может быть полезным.

Поэтому, если в блоке кода ничего не должно происходить, для такого блока необходим pass чтобы не создавать IndentationError . В качестве альтернативы можно использовать любой оператор (включая только термин, который нужно оценить, например, литерал Ellipsis ... или строку, чаще всего docstring), но в pass четко указано, что на самом деле ничего не должно происходить и не нужно чтобы быть фактически оценены и (по крайней мере временно) сохранены в памяти. Вот небольшой аннотированный сборник наиболее частых применений pass , которые пересекли мой путь - вместе с некоторыми комментариями по хорошей и плохой pratice.

• Игнорирование (все или) определенного типа Exception (пример из xml ):

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

  Примечание. Игнорирование всех типов повышений, как в следующем примере из pandas , обычно считается плохой практикой, поскольку оно также ловит исключения, которые, вероятно, должны быть переданы вызывающему абоненту, например KeyboardInterrupt или SystemExit (или даже HardwareIsOnFireError Как вы знаете вы не работаете в настраиваемом ящике с определенными определенными ошибками, о которых будет знать какое-либо вызывающее приложение?).

   try:
       os.unlink(filename_larry)
   except:
       pass
  

  Вместо этого используйте, по крайней мере, except Error: или в этом случае лучше, чем except OSError: считается гораздо лучшей практикой. Быстрый анализ всех модулей python, которые я установил, дал мне более 10% всех, except ...: pass инструкции except ...: pass выхватывают все исключения, поэтому он все еще является частым шаблоном в программировании на python.

• Получение класса исключений, который не добавляет нового поведения (например, в scipy ):

   class CompileError(Exception):
       pass
  

  Аналогично, классы, предназначенные как абстрактный базовый класс, часто имеют явные пустые __init__ или другие методы, которые должны получать подклассы. (например, pebl )

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

• Тестирование этого кода выполняется правильно для нескольких тестовых значений, не заботясь о результатах (из mpmath ):

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

• В определениях классов или функций часто док-строка уже существует, поскольку обязательное утверждение должно выполняться как единственное в блоке. В таких случаях блок может содержать pass в дополнение к docstring, чтобы сказать: «Это действительно предназначено, чтобы ничего не делать», например, в pebl :

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

• В некоторых случаях pass используется в качестве заполнителя, чтобы сказать: «Этот метод / класс / if-block / ... еще не реализован, но это будет место для этого», хотя я лично предпочитаю литерал Ellipsis ... (ПРИМЕЧАНИЕ: только python-3), чтобы строго различать это и преднамеренное «no-op» в предыдущем примере. Например, если я пишу модель с широкими штрихами, я могу написать

   def update_agent(agent):
       ... 
  

  где другие могут иметь

   def update_agent(agent):
       pass
  

  до

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

  как напоминание о том, чтобы заполнить функцию update_agent в более поздней точке, но запустите несколько тестов, чтобы проверить, ведет ли остальная часть кода, как предполагалось. (Третьим вариантом для этого случая является raise NotImplementedError . Это полезно, в частности, для двух случаев: «Этот абстрактный метод должен быть реализован каждым подклассом, нет общего способа определить его в этом базовом классе» или «Эта функция , с этим именем, еще не реализовано в этом выпуске, но это то, как его подпись будет выглядеть » )