Python Language
Godkännandet

Varför skulle du någonsin vilja be tolkaren att uttryckligen göra ingenting? Python har det syntaktiska kravet att kodblock (efter if , except def , class etc.) inte kan vara tomma.

Men ibland är ett tomt kodblock användbart i sig själv. En tom class blocket kan definine en ny, annan klass, såsom undantaget att kan fångas. Ett tomt except kan vara det enklaste sättet att uttrycka ”be om förlåtelse senare” om det inte fanns något att be om förlåtelse för. Om en iterator gör alla tunga lyft, kan en tom for loop bara för att köra iteratorn vara användbar.

Därför, om ingenting är tänkt att hända i ett kodblock, krävs ett pass för att ett sådant block inte ska producera en IndentationError . Alternativt kan alla uttalanden (inklusive bara en term som ska utvärderas, som Ellipsis literal ... eller en sträng, oftast en dokstring) användas, men pass gör klart att ingenting egentligen är tänkt att hända och inte behöver som faktiskt utvärderas och (åtminstone tillfälligt) lagras i minnet. Här är en liten kommenterad samling av de vanligaste användningarna av pass som passerade min väg - tillsammans med några kommentarer om god och dålig pratice.

• Ignorera (alla eller) en viss typ av Exception (exempel från xml ):

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

  Obs: Att ignorera alla typer av höjningar, som i följande exempel från pandas , anses vanligtvis dålig praxis, eftersom det också fångar undantag som antagligen ska vidarebefordras till den som ringer, t.ex. KeyboardInterrupt eller SystemExit (eller till och med HardwareIsOnFireError - Hur vet du du kör inte på en anpassad ruta med specifika fel definierade, vilket vissa samtalsprogram vill veta om?).

   try:
       os.unlink(filename_larry)
   except:
       pass
  

  Istället använder man åtminstone except Error: eller i detta fall helst except OSError: anses vara mycket bättre praxis. En snabb analys av alla Python-moduler som jag har installerat gav mig att mer än 10% av alla except ...: pass uttalanden fångar alla undantag, så det är fortfarande ett vanligt mönster i python-programmering.

• Erhålla en undantagsklass som inte lägger till nytt beteende (t.ex. i scipy ):

   class CompileError(Exception):
       pass
  

  På liknande sätt har klasser som är avsedda som abstrakt basklass ofta ett uttryckligt tomt __init__ eller andra metoder som underklasser är tänkta att härleda. (t.ex. pebl )

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

• Testa den koden körs korrekt för några testvärden utan att bry sig om resultaten (från mpmath ):

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

• I klass- eller funktionsdefinitioner är ofta en doktring redan på plats som det obligatoriska uttalandet som ska köras som det enda i blocket. I sådana fall kan blocket innehålla pass utöver doktringen för att säga ”Detta är verkligen avsett att göra ingenting.”, Till exempel i pebl :

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

• I vissa fall används pass som platshållare för att säga ”Denna metod / klass / om-block / / har inte implementerats ännu, men det här är platsen att göra det”, även om jag personligen föredrar Ellipsis bokstäverna ... (OBS: endast python-3) för att noggrant skilja mellan detta och den avsiktliga "no-op" i föregående exempel. Till exempel, om jag skriver en modell i breda streck, kanske jag skriver

   def update_agent(agent):
       ... 
  

  där andra kan ha

   def update_agent(agent):
       pass
  

  innan

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

  som en påminnelse om att fylla i update_agent funktionen vid en senare tidpunkt, men kör redan några tester för att se om resten av koden fungerar som avsett. (Ett tredje alternativ för detta fall är raise NotImplementedError . Detta är särskilt användbart i två fall: Antingen "Denna abstrakta metod bör implementeras av alla underklasser, det finns inget generiskt sätt att definiera det i denna basklass" , eller "Denna funktion , med det här namnet, är ännu inte implementerat i den här utgåvan, men det är så att dess signatur kommer att se ut ” )