7. Enkla statements

Ett enkelt statement består av en enda logisk rad. Flera enkla satser kan förekomma på en och samma rad, åtskilda av semikolon. Syntaxen för enkla satser är:

simple_stmt: expression_stmt
             | assert_stmt
             | assignment_stmt
             | augmented_assignment_stmt
             | annotated_assignment_stmt
             | pass_stmt
             | del_stmt
             | return_stmt
             | yield_stmt
             | raise_stmt
             | break_stmt
             | continue_stmt
             | import_stmt
             | future_stmt
             | global_stmt
             | nonlocal_stmt
             | type_stmt

7.1. Uttrycksförklaringar

Uttryckssatser används (oftast interaktivt) för att beräkna och skriva ett värde, eller (vanligtvis) för att anropa en procedur (en funktion som inte returnerar något meningsfullt resultat; i Python returnerar procedurer värdet None). Andra användningar av expression-satser är tillåtna och ibland användbara. Syntaxen för en expression-sats är:

expression_stmt: starred_expression

En expression-sats utvärderar uttrycksförteckningen (som kan vara ett enda uttryck).

I interaktivt läge, om värdet inte är None, konverteras det till en sträng med hjälp av den inbyggda funktionen repr() och den resulterande strängen skrivs till standardutdata på en rad för sig själv (utom om resultatet är None, så att proceduranrop inte orsakar någon utdata)

7.2. Uppdragsinformation

Assignment-satser används för att (om)binda namn till värden och för att ändra attribut eller objekt i föränderliga objekt:

assignment_stmt: (target_list "=")+ (starred_expression | yield_expression)
target_list:     target ("," target)* [","]
target:          identifier
                 | "(" [target_list] ")"
                 | "[" [target_list] "]"
                 | attributeref
                 | subscription
                 | slicing
                 | "*" target

(Se avsnitt Primärval för syntaxdefinitionerna för attributeref, subscription och slicing)

En assignment-sats utvärderar uttryckslistan (kom ihåg att detta kan vara ett enda uttryck eller en kommaseparerad lista, där det senare ger en tupel) och tilldelar det enda resulterande objektet till var och en av mållistorna, från vänster till höger.

Tilldelning definieras rekursivt beroende på målets form (lista). När ett mål är en del av ett föränderligt objekt (en attributreferens, prenumeration eller slicing), måste det föränderliga objektet i slutändan utföra tilldelningen och besluta om dess giltighet, och kan ge upphov till ett undantag om tilldelningen är oacceptabel. De regler som observeras av olika typer och de undantag som uppstår anges i samband med definitionen av objekttyperna (se avsnitt Standardtypens hierarki).

Tilldelning av ett objekt till en mållista, eventuellt innesluten i parenteser eller hakparenteser, definieras rekursivt på följande sätt.

• Om mållistan är ett enda mål utan efterföljande kommatecken, eventuellt inom parentes, tilldelas objektet till det målet.

• Else:

  • Om mållistan innehåller ett mål med en asterisk som prefix kallas det för ett ”stjärnmärkt” mål: Objektet måste vara en iterabel med minst lika många objekt som det finns mål i mållistan, minus ett. De första objekten i iterabeln tilldelas, från vänster till höger, till målen före det stjärnmärkta målet. De sista objekten i iterabeln tilldelas målen efter det stjärnmärkta målet. En lista över de återstående objekten i iterationen tilldelas sedan det stjärnmärkta målet (listan kan vara tom).

  • Annars: Objektet måste vara en iterabel med samma antal objekt som det finns mål i mållistan, och objekten tilldelas, från vänster till höger, till motsvarande mål.

Tilldelning av ett objekt till ett enda mål definieras rekursivt enligt följande.

• Om målet är en identifierare (namn):

  • Om namnet inte förekommer i en global- eller nonlocal-sats i det aktuella kodblocket: namnet är bundet till objektet i den aktuella lokala namnrymden.

  • Annars: namnet är bundet till objektet i den globala namnrymden eller den yttre namnrymden som bestäms av nonlocal, respektive.

  Namnet reboundas om det redan var bundet. Detta kan leda till att referensantalet för det objekt som tidigare var bundet till namnet når noll, vilket leder till att objektet avallokeras och att dess destruktor (om det har en sådan) anropas.

• Om målet är en attributreferens: Det primära uttrycket i referensen utvärderas. Det bör resultera i ett objekt med tilldelningsbara attribut; om så inte är fallet anges TypeError. Objektet ombeds sedan att tilldela det tilldelade objektet till det givna attributet; om det inte kan utföra tilldelningen utlöses ett undantag (vanligtvis men inte nödvändigtvis AttributeError).

  Observera: Om objektet är en klassinstans och attributreferensen förekommer på båda sidor om tilldelningsoperatorn, kan uttrycket på höger sida, a.x, få åtkomst till antingen ett instansattribut eller (om inget instansattribut finns) ett klassattribut. Målet på vänstersidan, a.x, anges alltid som ett instansattribut och skapas vid behov. De två förekomsterna av a.x behöver alltså inte nödvändigtvis referera till samma attribut: om uttrycket på högersidan refererar till ett klassattribut, skapar vänstersidan ett nytt instansattribut som mål för tilldelningen:

  klass Cls:
      x = 3 # klassvariabel
  inst = Cls()
  inst.x = inst.x + 1 # skriver inst.x som 4 och lämnar Cls.x som 3
  

  Denna beskrivning gäller inte nödvändigtvis deskriptorattribut, t.ex. egenskaper som skapats med property().

• Om målet är en prenumeration: Det primära uttrycket i referensen utvärderas. Det bör ge antingen ett muterbart sekvensobjekt (t.ex. en lista) eller ett mappningsobjekt (t.ex. en ordbok). Därefter utvärderas det subskriberade uttrycket.

  Om primären är ett muterbart sekvensobjekt (t.ex. en lista) måste subscript ge ett heltal. Om det är negativt adderas sekvensens längd till det. Det resulterande värdet måste vara ett icke-negativt heltal som är mindre än sekvensens längd, och sekvensen uppmanas att tilldela det tilldelade objektet till sitt objekt med det indexet. Om indexet är utanför intervallet, IndexError (tilldelning till en abonnerad sekvens kan inte lägga till nya objekt i en lista).

  Om det primära är ett mappningsobjekt (t.ex. en ordbok) måste subskriptionen ha en typ som är kompatibel med mappningens nyckeltyp, och mappningen ombeds sedan skapa ett nyckel/värde-par som mappar subskriptionen till det tilldelade objektet. Detta kan antingen ersätta ett befintligt nyckel/värde-par med samma nyckelvärde eller infoga ett nytt nyckel/värde-par (om det inte finns någon nyckel med samma värde).

  För användardefinierade objekt anropas metoden __setitem__() med lämpliga argument.

• Om målet är en skivning: Det primära uttrycket i referensen utvärderas. Det bör ge ett muterbart sekvensobjekt (t.ex. en lista). Det tilldelade objektet ska vara ett sekvensobjekt av samma typ. Därefter utvärderas de nedre och övre gränsuttrycken, i den mån de finns; standardvärdena är noll och sekvensens längd. Gränserna bör utvärderas till heltal. Om någon av gränserna är negativ adderas sekvensens längd till den. De resulterande gränserna klipps så att de ligger mellan noll och sekvensens längd, inklusive. Slutligen ombeds sekvensobjektet att ersätta skivan med objekten i den tilldelade sekvensen. Slice-längden kan skilja sig från längden på den tilldelade sekvensen och därmed ändra längden på målsekvensen, om målsekvensen tillåter det.

I den nuvarande implementeringen anses syntaxen för mål vara densamma som för uttryck, och ogiltig syntax avvisas under kodgenereringsfasen, vilket orsakar mindre detaljerade felmeddelanden.

Även om definitionen av tilldelning innebär att överlappningar mellan vänster och höger sida är ”samtidiga” (t.ex. a, b = b, a byter två variabler), sker överlappningar inom samlingen av variabler som tilldelats till vänster till höger, vilket ibland leder till förvirring. Till exempel skriver följande program ut [0, 2]:

x = [0, 1]
i = 0
i, x[i] = 1, 2 # i uppdateras, sedan uppdateras x[i]
skriv ut(x)

Se även

PEP 3132 - Utökad uppackning av iterabel

Specifikationen för funktionen *target.

7.2.1. Utökade uppdragsbeskrivningar

Augmented assignment är en kombination av en binär operation och en assignment-sats i en och samma sats:

augmented_assignment_stmt: augtarget augop (expression_list | yield_expression)
augtarget:                 identifier | attributeref | subscription | slicing
augop:                     "+=" | "-=" | "*=" | "@=" | "/=" | "//=" | "%=" | "**="
                           | ">>=" | "<<=" | "&=" | "^=" | "|="

(Se avsnitt Primärval för syntaxdefinitioner av de tre sista symbolerna)

En utökad tilldelning utvärderar målet (som, till skillnad från normala tilldelningssatser, inte kan vara en uppackning) och uttryckslistan, utför den binära operation som är specifik för tilldelningstypen på de två operanderna och tilldelar resultatet till det ursprungliga målet. Målet utvärderas bara en gång.

En utökad uppgift som x += 1 kan skrivas om till x = x + 1 för att uppnå en liknande, men inte exakt lika stor effekt. I den utökade versionen utvärderas x bara en gång. Dessutom utförs den faktiska operationen på plats när det är möjligt, vilket innebär att det gamla objektet modifieras istället för att skapa ett nytt objekt och tilldela det till målet.

Till skillnad från normala uppdrag utvärderar utökade uppdrag vänstersidan innan högersidan utvärderas. Till exempel, a[i] += f(x) letar först upp a[i], sedan utvärderar den f(x) och utför additionen, och slutligen skriver den tillbaka resultatet till a[i].

Med undantag för tilldelning till tupler och flera mål i en enda sats, hanteras tilldelningen som utförs av augmented assignment-satser på samma sätt som normala tilldelningar. På samma sätt, med undantag för det möjliga in-place-beteendet, är den binära operation som utförs av augmented assignment densamma som de normala binära operationerna.

För mål som är attributreferenser gäller samma avrådan om klass- och instansattribut som för vanliga uppdrag.

7.2.2. Kommenterade uppdragsbeskrivningar

Annotation assignment är kombinationen, i en enda sats, av en variabel- eller attributannotation och en valfri assignment-sats:

annotated_assignment_stmt: augtarget ":" expression
                           ["=" (starred_expression | yield_expression)]

Skillnaden mot normal Uppdragsinformation är att endast ett enda mål är tillåtet.

Tilldelningsmålet anses vara ”enkelt” om det består av ett enda namn som inte är inneslutet i parenteser. För enkla tilldelningsobjekt, om de finns i klass- eller modulomfång, samlas anteckningarna i en latent utvärderad annotation scope. Anteckningarna kan utvärderas med hjälp av attributet __annotations__ för en klass eller modul, eller med hjälp av faciliteterna i modulen annotationlib.

Om tilldelningsmålet inte är enkelt (ett attribut, en subskriptnod eller ett namn inom parentes) utvärderas annotationen aldrig.

Om ett namn annoteras i ett funktionsomfång är namnet lokalt för detta omfång. Annoteringar utvärderas och lagras aldrig i funktionsscopes.

Om den högra sidan är närvarande, utför ett annoterat uppdrag det faktiska uppdraget som om det inte fanns någon annotation närvarande. Om den högra sidan inte finns för ett uttrycksmål utvärderar tolken målet förutom det sista anropet av __setitem__() eller __setattr__().

Se även

PEP 526 - Syntax för variabelkommentarer

Förslaget som lade till syntax för att kommentera typerna av variabler (inklusive klassvariabler och instansvariabler), istället för att uttrycka dem genom kommentarer.

PEP 484 - Typ av ledtrådar

Förslaget som lade till modulen typing för att tillhandahålla en standardsyntax för typannoteringar som kan användas i verktyg för statisk analys och IDE:er.

Ändrad i version 3.8: Nu tillåter annoterade uppdrag samma uttryck på höger sida som vanliga uppdrag. Tidigare orsakade vissa uttryck (t.ex. tupeluttryck som inte var föräldradefinierade) ett syntaxfel.

Ändrad i version 3.14: Anteckningar utvärderas nu i en separat annotation scope. Om tilldelningsmålet inte är enkelt utvärderas aldrig anteckningar.

7.3. assert-satsen

Assert-satser är ett bekvämt sätt att infoga felsökningssatser i ett program:

assert_stmt: "assert" expression ["," expression]

Den enkla formen, assert expression, är likvärdig med

om __debug__:
    if not expression: raise AssertionError

Den utökade formen, assert expression1, expression2, är likvärdig med

om __debug__:
    if not expression1: raise AssertionError(expression2)

Dessa ekvivalenser förutsätter att __debug__ och AssertionError refererar till de inbyggda variablerna med dessa namn. I den aktuella implementationen är den inbyggda variabeln __debug__ True under normala omständigheter, False när optimering begärs (kommandoradsalternativ -O). Den aktuella kodgeneratorn genererar ingen kod för en assert-sats när optimering begärs vid kompileringstillfället. Observera att det inte är nödvändigt att inkludera källkoden för det uttryck som misslyckades i felmeddelandet; den kommer att visas som en del av stackspårningen.

Tilldelningar till __debug__ är olagliga. Värdet för den inbyggda variabeln bestäms när tolken startar.

7.4. pass-satsen

pass_stmt: "pass"

pass är en null operation — när den utförs händer ingenting. Det är användbart som en platshållare när ett uttalande krävs syntaktiskt, men ingen kod behöver exekveras, till exempel:

def f(arg): pass # en funktion som inte gör någonting (ännu)

class C: pass # en klass som inte har några metoder (ännu)

7.5. del-satsen

del_stmt: "del" target_list

Deletion definieras rekursivt på samma sätt som assignment definieras. I stället för att beskriva det i detalj kommer här några ledtrådar.

Radering av en mållista innebär att varje mål raderas rekursivt, från vänster till höger.

Om ett namn raderas tas bindningen av namnet bort från den lokala eller globala namnrymden, beroende på om namnet förekommer i en global-sats i samma kodblock. Om namnet är obundet kommer ett NameError undantag att uppstå.

Radering av attributreferenser, prenumerationer och skivningar skickas till det primära objekt som berörs; radering av en skivning är i allmänhet likvärdig med tilldelning av en tom skivning av rätt typ (men även detta bestäms av det skivade objektet).

Ändrad i version 3.2: Tidigare var det olagligt att ta bort ett namn från den lokala namnrymden om det förekom som en fri variabel i ett nästlat block.

7.6. Nyckelordet: !return-satsen

return_stmt: "return" [expression_list]

return får endast förekomma syntaktiskt nästlad i en funktionsdefinition, inte inom en nästlad klassdefinition.

Om det finns en uttrycksförteckning utvärderas den, annars ersätts den med None.

return lämnar det aktuella funktionsanropet med uttrycksförteckningen (eller None) som returvärde.

När return skickar ut kontrollen från en try-sats med en finally-sats, exekveras finally-satsen innan funktionen verkligen lämnar funktionen.

I en generatorfunktion anger return att generatorn är klar och kommer att orsaka att StopIteration aktiveras. Det returnerade värdet (om något) används som ett argument för att konstruera StopIteration och blir attributet StopIteration.value.

I en asynkron generatorfunktion anger en tom return-sats att den asynkrona generatorn är klar och kommer att orsaka att StopAsyncIteration aktiveras. En icke-tom return-sats är ett syntaxfel i en asynkron generatorfunktion.

7.7. yield-satsen

yield_stmt: yield_expression

En yield-sats är semantiskt ekvivalent med en yield-uttryck. yield-satsen kan användas för att utelämna de parenteser som annars skulle krävas i motsvarande yield-uttryckssats. Till exempel kan yield-satserna

avkastning <expr>
avkastning från <expr>

är ekvivalenta med uttrycket yield statements

(avkastning <expr>)
(avkastning från <expr>)

Yield-uttryck och -satser används endast när man definierar en generator-funktion, och de används endast i generatorfunktionens kropp. Att använda yield i en funktionsdefinition är tillräckligt för att definitionen ska skapa en generatorfunktion i stället för en normal funktion.

För fullständig information om yield semantik, se avsnittet Avkastningsuttryck.

7.8. raise-satsen

raise_stmt: "raise" [expression ["from" expression]]

Om inga uttryck finns kommer raise att återskapa det undantag som för närvarande hanteras, vilket också kallas det aktiva undantaget. Om det för närvarande inte finns något aktivt undantag, kommer ett RuntimeError undantag att uppstå som indikerar att detta är ett fel.

Annars utvärderar raise det första uttrycket som undantagsobjektet. Det måste vara antingen en underklass eller en instans av BaseException. Om det är en klass, kommer undantagsinstansen att erhållas när det behövs genom att instansiera klassen utan argument.

Undantagets type är undantagsinstansens klass, och value är själva instansen.

Ett traceback-objekt skapas normalt automatiskt när ett undantag uppstår och kopplas till det som attributet __traceback__. Du kan skapa ett undantag och ställa in din egen traceback i ett steg med hjälp av undantagsmetoden with_traceback() (som returnerar samma undantagsinstans, med dess traceback inställd på sitt argument), så här:

raise Exception("foo inträffade").with_traceback(tracebackobj)

Klausulen from används för exception chaining: om den ges måste det andra uttrycket vara en annan exceptionklass eller -instans. Om det andra uttrycket är en undantagsinstans kommer den att kopplas till det uppkomna undantaget som attributet __cause__ (som är skrivbart). Om uttrycket är en undantagsklass instansieras klassen och den resulterande undantagsinstansen kopplas till det uppkomna undantaget som attributet __cause__. Om det uppkomna undantaget inte hanteras skrivs båda undantagen ut:

>>> try:
...     print(1 / 0)
... except Exception as exc:
...     raise RuntimeError("Something bad happened") from exc
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
    print(1 / 0)
          ~~^~~
ZeroDivisionError: division by zero

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
    raise RuntimeError("Something bad happened") from exc
RuntimeError: Something bad happened

En liknande mekanism fungerar implicit om ett nytt undantag tas upp när ett undantag redan håller på att hanteras. Ett undantag kan hanteras när en except- eller finally-sats, eller en with-sats, används. Det tidigare undantaget bifogas då som det nya undantagets __context__-attribut:

>>> try:
...     print(1 / 0)
... except:
...     raise RuntimeError("Something bad happened")
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
    print(1 / 0)
          ~~^~~
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
    raise RuntimeError("Something bad happened")
RuntimeError: Something bad happened

Undantagskedjor kan uttryckligen undertryckas genom att ange None i from-satsen:

>>> try:
...     print(1 / 0)
... except:
...     raise RuntimeError("Something bad happened") from None
...
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
RuntimeError: Something bad happened

Ytterligare information om undantag finns i avsnitt Undantag, och information om hantering av undantag finns i avsnitt try-satsen.

Ändrad i version 3.3: None är nu tillåtet som Y i raise X from Y.

Lagt till attributet __suppress_context__ för att undertrycka automatisk visning av undantagskontexten.

Ändrad i version 3.11: Om spårningen av det aktiva undantaget ändras i en except-sats, kommer en efterföljande raise-sats att återaktivera undantaget med den ändrade spårningen. Tidigare aktiverades undantaget på nytt med den traceback som det hade när det fångades.

7.9. break-satsen

break_stmt: "break"

break kan endast förekomma syntaktiskt inbäddad i en for- eller while-loop, men inte inbäddad i en funktions- eller klassdefinition inom den loopen.

Den avslutar den närmaste omslutande slingan och hoppar över den valfria else-satsen om slingan har en sådan.

Om en for-loop avslutas med break, behåller loopens kontrollmål sitt aktuella värde.

När break skickar kontrollen ut ur en try-sats med en finally-klausul, exekveras finally-klausulen innan den lämnar slingan.

7.10. Nyckelordet: !continue-satsen

continue_stmt: "continue"

continue kan bara förekomma syntaktiskt inbäddad i en for eller while-loop, men inte inbäddad i en funktions- eller klassdefinition inom den loopen. Den fortsätter med nästa cykel i den närmaste omslutande slingan.

När continue skickar ut kontrollen från en try-sats med en finally-klausul, utförs finally-klausulen innan nästa loopcykel påbörjas.

7.11. Nyckelordet: !import-satsen

import_stmt:     "import" module ["as" identifier] ("," module ["as" identifier])*
                 | "from" relative_module "import" identifier ["as" identifier]
                 ("," identifier ["as" identifier])*
                 | "from" relative_module "import" "(" identifier ["as" identifier]
                 ("," identifier ["as" identifier])* [","] ")"
                 | "from" relative_module "import" "*"
module:          (identifier ".")* identifier
relative_module: "."* module | "."+

Den grundläggande importsatsen (ingen from-klausul) utförs i två steg:

1. hitta en modul, ladda och initiera den om det behövs

2. definiera ett eller flera namn i den lokala namnrymden för det scope där import-satsen förekommer.

Om deklarationen innehåller flera klausuler (åtskilda med kommatecken) utförs de två stegen separat för varje klausul, precis som om klausulerna hade varit uppdelade i enskilda importdeklarationer.

Detaljerna i det första steget, att hitta och ladda moduler, beskrivs mer ingående i avsnittet om import system, där även de olika typerna av paket och moduler som kan importeras beskrivs, liksom alla de hooks som kan användas för att anpassa importsystemet. Observera att fel i det här steget antingen kan bero på att modulen inte kunde hittas, eller att ett fel inträffade under initieringen av modulen, vilket inkluderar exekvering av modulens kod.

Om den begärda modulen hämtas framgångsrikt kommer den att göras tillgänglig i det lokala namnrymden på ett av tre sätt:

• Om modulnamnet följs av as, så är namnet som följer efter as bundet direkt till den importerade modulen.

• Om inget annat namn anges och den modul som importeras är en modul på högsta nivån, binds modulens namn i det lokala namnrymden som en referens till den importerade modulen

• Om den modul som importeras inte är en toppnivåmodul, binds namnet på det toppnivåpaket som innehåller modulen i den lokala namnrymden som en referens till toppnivåpaketet. Den importerade modulen måste nås med hjälp av dess fullständiga kvalificerade namn i stället för direkt

I formuläret from används en något mer komplex process:

1. hittar den modul som anges i from-satsen, laddar och initierar den vid behov;

2. för var och en av de identifierare som anges i import-klausulerna:

   1. kontrollera om den importerade modulen har ett attribut med det namnet

   2. om inte, försök att importera en undermodul med det namnet och kontrollera sedan den importerade modulen igen för det attributet

   3. om attributet inte hittas, uppstår ImportError.

   4. annars lagras en referens till värdet i den lokala namnrymden med hjälp av namnet i as-satsen om det finns, annars med hjälp av attributnamnet

Exempel:

import foo                 # foo imported and bound locally
import foo.bar.baz         # foo, foo.bar, and foo.bar.baz imported, foo bound locally
import foo.bar.baz as fbb  # foo, foo.bar, and foo.bar.baz imported, foo.bar.baz bound as fbb
from foo.bar import baz    # foo, foo.bar, and foo.bar.baz imported, foo.bar.baz bound as baz
from foo import attr       # foo imported and foo.attr bound as attr

Om listan med identifierare ersätts av en stjärna ('*'), binds alla publika namn som definieras i modulen i den lokala namnrymden för det scope där import-satsen förekommer.

De publika namn som definieras av en modul bestäms genom att kontrollera modulens namnrymd för en variabel som heter __all__; om den definieras måste den vara en sekvens av strängar som är namn som definieras eller importeras av den modulen. De namn som anges i __all__ anses alla vara publika och måste existera. Om __all__ inte är definierat, inkluderar uppsättningen av publika namn alla namn som finns i modulens namnrymd och som inte börjar med ett understreck ('_'). __all__ bör innehålla hela det publika API:et. Syftet är att undvika oavsiktlig export av objekt som inte är en del av API:et (t.ex. biblioteksmoduler som importerats och används i modulen).

Jokerteckenformen av import — from module import * — är endast tillåten på modulnivå. Försök att använda den i klass- eller funktionsdefinitioner kommer att ge upphov till ett SyntaxError.

När du anger vilken modul som ska importeras behöver du inte ange modulens absoluta namn. När en modul eller ett paket ingår i ett annat paket är det möjligt att göra en relativ import inom samma topp-paket utan att behöva nämna paketnamnet. Genom att använda ledande punkter i den angivna modulen eller paketet efter from kan du ange hur högt upp i den aktuella pakethierarkin du ska gå utan att ange exakta namn. En ledande prick betyder det aktuella paketet där modulen som gör importen finns. Två punkter innebär en paketnivå uppåt. Tre punkter är två nivåer högre, osv. Så om du kör from . import mod från en modul i paketet pkg kommer du att importera pkg.mod. Om du exekverar from ..subpkg2 import mod från pkg.subpkg1 kommer du att importera pkg.subpkg2.mod. Specifikationen för relativ import finns i avsnittet Paket Relativ import.

importlib.import_module() tillhandahålls för att stödja applikationer som dynamiskt bestämmer vilka moduler som ska laddas.

Skapar en auditing event import med argumenten module, filename, sys.path, sys.meta_path, sys.path_hooks.

7.11.1. Framtida uttalanden

En future statement är ett direktiv till kompilatorn att en viss modul ska kompileras med syntax eller semantik som kommer att finnas tillgänglig i en specificerad framtida version av Python där funktionen blir standard.

Future Statement är avsett att underlätta migrering till framtida versioner av Python som introducerar inkompatibla förändringar av språket. Det tillåter användning av de nya funktionerna per modul innan den version där funktionen blir standard.

future_stmt: "from" "__future__" "import" feature ["as" identifier]
             ("," feature ["as" identifier])*
             | "from" "__future__" "import" "(" feature ["as" identifier]
             ("," feature ["as" identifier])* [","] ")"
feature:     identifier

En framtidsförklaring måste stå längst upp i modulen. De enda rader som kan förekomma före en framtidsförklaring är:

• modulens dokumentsträng (om sådan finns),

• kommentarer,

• tomma rader och

• andra framtida uttalanden.

Den enda funktion som kräver användning av future statement är annotations (se PEP 563).

Alla historiska funktioner som aktiveras av future statement känns fortfarande igen av Python 3. Listan inkluderar absolute_import, division, generators, generator_stop, unicode_literals, print_function, nested_scopes och with_statement. De är alla överflödiga eftersom de alltid är aktiverade och endast behålls för bakåtkompatibilitet.

Ett framtida uttalande identifieras och behandlas speciellt vid kompileringstillfället: Ändringar i semantiken för kärnkonstruktioner implementeras ofta genom att annan kod genereras. Det kan till och med vara så att en ny funktion introducerar ny inkompatibel syntax (t.ex. ett nytt reserverat ord), i vilket fall kompilatorn kan behöva analysera modulen på ett annat sätt. Sådana beslut kan inte skjutas upp till runtime.

För varje given version vet kompilatorn vilka funktionsnamn som har definierats och ger upphov till ett fel vid kompilering om ett framtida uttalande innehåller en funktion som kompilatorn inte känner till.

Den direkta körtidssemantiken är densamma som för alla import-satser: det finns en standardmodul __future__, som beskrivs senare, och den kommer att importeras på vanligt sätt när future-satsen exekveras.

Den intressanta semantiken för körtiden beror på den specifika funktion som möjliggörs av framtidsuttalandet.

Observera att det inte finns något speciellt med uttalandet:

importera __future__ [som namn]

Det är inte en future-sats, utan en vanlig import-sats utan någon speciell semantik eller syntaxrestriktioner.

Kod som kompileras genom anrop till de inbyggda funktionerna exec() och compile() som förekommer i en modul M som innehåller en framtidsdeklaration kommer som standard att använda den nya syntax eller semantik som är associerad med framtidsdeklarationen. Detta kan styras med valfria argument till compile() — se dokumentationen för den funktionen för detaljer.

En future-sats som skrivs vid en interaktiv tolks prompt kommer att gälla under resten av tolksessionen. Om en tolk startas med alternativet -i, får ett skriptnamn som ska exekveras och skriptet innehåller en future-sats, kommer den att gälla i den interaktiva session som startas efter att skriptet har exekverats.

Se även

PEP 236 - Tillbaka till __framtiden__

Det ursprungliga förslaget till mekanismen __future__.

7.12. global-satsen

global_stmt: "global" identifier ("," identifier)*

Satsen global gör att de listade identifierarna tolkas som globaler. Det skulle vara omöjligt att tilldela en global variabel utan global, även om fria variabler kan referera till globaler utan att vara deklarerade som globala.

Satsen global gäller för hela omfattningen av en funktions eller klass kropp. Ett SyntaxError uppstår om en variabel används eller tilldelas innan den har deklarerats globalt i scopet.

Programmerarens anmärkning: global är ett direktiv till parsern. Det gäller endast för kod som analyseras samtidigt som global-satsen. I synnerhet påverkar inte en global-sats som ingår i en sträng eller ett kodobjekt som levereras till den inbyggda funktionen exec() kodblocket som innehåller funktionsanropet, och kod som ingår i en sådan sträng påverkas inte av global-satser i koden som innehåller funktionsanropet. Detsamma gäller för funktionerna eval() och compile().

7.13. nonlocal-satsen

nonlocal_stmt: "nonlocal" identifier ("," identifier)*

När definitionen av en funktion eller klass är kapslad (innesluten) i definitionerna av andra funktioner, är dess icke-lokala scope de lokala scopen för de inneslutande funktionerna. Satsen nonlocal gör att de listade identifierarna refererar till namn som tidigare bundits i icke-lokala scopes. Det gör det möjligt för inkapslad kod att återbinda sådana icke-lokala identifierare. Om ett namn är bundet i mer än ett icke-lokalt scope, används den närmaste bindningen. Om ett namn inte är bundet i något icke-lokalt scope, eller om det inte finns något icke-lokalt scope, genereras ett SyntaxError.

Deklarationen nonlocal gäller för hela omfattningen av en funktions eller klass kropp. Ett SyntaxError uppstår om en variabel används eller tilldelas innan den har deklarerats icke-lokalt i scopet.

Se även

PEP 3104 - Åtkomst till namn i ytterområden (Outer Scopes)

Specifikationen för nonlocal statement.

Programmer’s note: nonlocal är ett direktiv till parsern och gäller endast för kod som parsas tillsammans med den. Se anmärkningen för global.

7.14. type-satsen

type_stmt: 'type' identifier [type_params] "=" expression

Satsen type deklarerar ett typalias, som är en instans av typing.TypeAliasType.

Exempelvis skapas ett typalias med följande instruktion:

typ Point = tuple[float, float]

Denna kod motsvarar ungefär:

annotation-def VALUE_OF_Point():
    return tuple[float, float]
Point = typing.TypeAliasType("Point", VALUE_OF_Point())

annotation-def anger en :annotation scope, som i stort sett beter sig som en funktion, men med flera små skillnader.

Värdet på typaliaset utvärderas i annotationens scope. Det utvärderas inte när typaliaset skapas, utan först när värdet nås via typaliasets attribut __value__ (se Ledig utvärdering). Detta gör att typaliaset kan referera till namn som ännu inte är definierade.

Typaliaser kan göras generiska genom att lägga till en typparameterlista efter namnet. Se Alias för generiska typer för mer information.

type är ett mjukt nyckelord.

Tillagd i version 3.12.

Se även

PEP 695 - Syntax för typparameter

Införde type statement och syntax för generiska klasser och funktioner.