2. Lexikalisk analys

Ett Python-program läses av en parser. Indata till parsern är en ström av tokens, som genereras av den lexikala analysatorn (även känd som tokenizer). I det här kapitlet beskrivs hur den lexikala analysatorn delar upp en fil i tokens.

Python läser programtext som Unicode-kodpunkter; kodningen av en källfil kan anges med en kodningsdeklaration och standardvärdet är UTF-8, se PEP 3120 för detaljer. Om källfilen inte kan avkodas uppstår ett SyntaxError.

2.1. Linjestruktur

Ett Python-program är indelat i ett antal logiska rader.

2.1.1. Logiska linjer

Slutet på en logisk rad representeras av token NEWLINE. Satser kan inte korsa logiska linjers gränser utom där NEWLINE tillåts av syntaxen (t.ex. mellan satser i sammansatta satser). En logisk linje konstrueras från en eller flera fysiska linjer genom att följa explicit eller implicit line joining-reglerna.

2.1.2. Fysiska linjer

En fysisk rad är en sekvens av tecken som avslutas med någon av följande radavslutningssekvenser:

• unix-formuläret med ASCII LF (radmatning),

• windows-formuläret med hjälp av ASCII-sekvensen CR LF (retur följt av radmatning),

• formuläret ”Classic Mac OS” med ASCII-tecknet CR (return).

Oavsett plattform ersätts var och en av dessa sekvenser med ett enda ASCII LF-tecken (linefeed). (Detta görs även inom stränglitteraler.) Varje rad kan använda vilken som helst av sekvenserna; de behöver inte vara konsekventa inom en fil.

Slutet på inmatningen fungerar också som en implicit terminator för den sista fysiska linjen.

Formellt sett:

newline: <ASCII LF> | <ASCII CR> <ASCII LF> | <ASCII CR>

2.1.3. Kommentarer

En kommentar börjar med ett hash-tecken (#) som inte är en del av en bokstavlig sträng och slutar vid slutet av den fysiska raden. En kommentar innebär slutet på den logiska raden om inte de implicita reglerna för radförlängning används. Kommentarer ignoreras av syntaxen.

2.1.4. Deklarationer för kodning

Om en kommentar på den första eller andra raden i Python-skriptet matchar det reguljära uttrycket coding[=:]\s*([-\w.]+), behandlas denna kommentar som en kodningsdeklaration; den första gruppen i detta uttryck anger kodningen för källkodsfilen. Kodningsdeklarationen måste stå på en egen rad. Om det är den andra raden, måste den första raden också vara en rad med enbart kommentarer. De rekommenderade formerna för ett kodningsuttryck är

# -*- kodning: <encoding-name> -*-

som också känns igen av GNU Emacs, och

# vim:filkodning=<encoding-name>

som är erkänd av Bram Moolenaars VIM.

Om ingen kodningsdeklaration hittas är standardkodningen UTF-8. Om den implicita eller explicita kodningen av en fil är UTF-8 ignoreras en initial UTF-8 byteordermarkering (b'\xef\xbb\xbf') i stället för att utgöra ett syntaxfel.

Om en kodning deklareras, måste kodningsnamnet kännas igen av Python (se Standardkodningar). Kodningen används för all lexikal analys, inklusive stränglitteraler, kommentarer och identifierare.

All lexikal analys, inklusive stränglitteraler, kommentarer och identifierare, fungerar på Unicode-text som avkodas med hjälp av källkodningen. Alla Unicode-kodpunkter, utom kontrolltecknet NUL, kan förekomma i Python-källan.

source_character:  <any Unicode code point, except NUL>

2.1.5. Explicit sammanfogning av linjer

Två eller flera fysiska rader kan sammanfogas till logiska rader med hjälp av backslash-tecken (\) enligt följande: När en fysisk rad slutar med ett backslash-tecken som inte är en del av en bokstavlig sträng eller en kommentar, sammanfogas den med den följande och bildar en enda logisk rad, varvid backslash-tecknet och det följande radslutstecknet tas bort. Till exempel:

om 1900 < år < 2100 och 1 <= månad <= 12 \
   och 1 <= dag <= 31 och 0 <= timme < 24 \
   och 0 <= minut <= 60 och 0 <= sekund <= 60: # Ser ut som ett giltigt datum
        returnera 1

En rad som slutar med ett backslash kan inte innehålla en kommentar. En backslash fortsätter inte en kommentar. En backslash fortsätter inte en token utom för stränglitteraler (dvs. andra tokens än stränglitteraler kan inte delas över fysiska rader med hjälp av en backslash). Ett backslash är olagligt på andra ställen på en rad utanför en stränglitteral.

2.1.6. Implicit sammanfogning av linjer

Uttryck inom parenteser, hakparenteser eller hakklamrar kan delas upp på mer än en fysisk rad utan att använda bindestreck. Till exempel:

month_names = ['Januari', 'Februari', 'Maart', # Dessa är de nederländska
               'April', 'Mei', 'Juni', # nederländska namnen
               'Juli', 'Augustus', 'September', # för månaderna
               'Oktober', 'November', 'December']   # av året

Implicit fortsatta rader kan innehålla kommentarer. Indraget på fortsättningsraderna är inte viktigt. Tomma fortsättningsrader är tillåtna. Det finns ingen NEWLINE-token mellan implicita fortsättningsrader. Implicit fortsatta rader kan också förekomma inom trippelciterade strängar (se nedan); i så fall kan de inte innehålla kommentarer.

2.1.7. Tomma rader

En logisk rad som bara innehåller mellanslag, tabbar, formfeeds och eventuellt en kommentar ignoreras (dvs. ingen NEWLINE token genereras). Vid interaktiv inmatning av satser kan hanteringen av en tom rad skilja sig åt beroende på hur read-eval-print-loopen implementeras. I den interaktiva standardtolken avslutar en helt tom logisk rad (dvs. en rad som inte ens innehåller blanksteg eller en kommentar) ett flerradigt uttalande.

2.1.8. Indrag

Ledande blanksteg (mellanslag och tabbar) i början av en logisk rad används för att beräkna indragningsnivån på raden, som i sin tur används för att bestämma grupperingen av satser.

Tabbar ersätts (från vänster till höger) med ett till åtta mellanslag så att det totala antalet tecken fram till och med ersättningen är en multipel av åtta (detta är tänkt att vara samma regel som används av Unix). Det totala antalet mellanslag före det första tecknet som inte är blankt avgör sedan radens indrag. Indrag kan inte delas upp på flera fysiska rader med hjälp av backslash; blanksteg fram till första backslash bestämmer indraget.

Indragning avvisas som inkonsekvent om en källfil blandar tabbar och mellanslag på ett sätt som gör att betydelsen är beroende av värdet av en tabb i mellanslag; ett TabError uppstår i så fall.

Kompatibilitet mellan plattformar: På grund av textredigerare på andra plattformar än UNIX är det oklokt att använda en blandning av mellanslag och tabbar för indragning i en och samma källfil. Det bör också noteras att olika plattformar uttryckligen kan begränsa den maximala indragningsnivån.

Ett formfeed-tecken kan finnas i början av raden; det kommer att ignoreras vid indragningsberäkningarna ovan. Formfeed-tecken som förekommer på andra ställen i det inledande blanksteget har en odefinierad effekt (de kan t.ex. återställa blankstegsräkningen till noll).

Indenteringsnivåerna för på varandra följande rader används för att generera INDENT och DEDENT tokens, med hjälp av en stack, enligt följande.

Innan den första raden i filen läses läggs en enda nolla på stacken; den kommer aldrig att plockas bort igen. Siffrorna som läggs på stacken är alltid strikt ökande från botten till toppen. I början av varje logisk rad jämförs radens indragningsnivå med toppen av stacken. Om den är lika stor händer ingenting. Om den är större läggs den på stacken och en INDENT-token genereras. Om det är mindre måste det vara ett av de tal som förekommer på stacken; alla tal på stacken som är större poppas bort och för varje tal som poppas bort genereras en DEDENT-token. I slutet av filen genereras en DEDENT-token för varje tal som är större än noll och som finns kvar på stapeln.

Här är ett exempel på en korrekt (men förvirrande) indragen bit Python-kod:

def perm(l):
        # Beräkna listan över alla permutationer av l
    om len(l) <= 1:
                  return [l]
    r = []
    for i in range(len(l)):
             s = l[:i] + l[i+1:]
             p = perm(s)
             för x i p:
              r.append(l[i:i+1] + x)
    returnera r

Följande exempel visar olika indragningsfel:

 def perm(l):                       # fel: första raden indragen
for i in range(len(l)):             # fel: inte indragen
    s = l[:i] + l[i+1:]
        p = perm(l[:i] + l[i+1:]) # fel: oväntat indrag
        för x i p:
                r.append(l[i:i+1] + x)
            return r # fel: inkonsekvent indrag

(I själva verket upptäcks de tre första felen av parsern; endast det sista felet upptäcks av den lexikala analysatorn — indragningen av return r matchar inte en nivå som poppats från stacken)

2.1.9. Mellanslag mellan symboler

Förutom i början av en logisk rad eller i stränglitteraler kan blankstegstecknen mellanslag, tabb och formfeed användas omväxlande för att separera tokens. Blanksteg behövs mellan två tokens endast om deras sammankoppling annars skulle kunna tolkas som en annan token. Till exempel är ab en token, men a b är två tokens. Men +a och + a ger båda två tokens, + och a, eftersom +a inte är en giltig token.

2.1.10. Slutmarkör

I slutet av en icke-interaktiv inmatning genererar den lexikala analysatorn en ENDMARKER-token.

2.2. Andra symboler

Förutom NEWLINE, INDENT och DEDENT finns följande kategorier av tokens: identifierare och nyckelord (NAME), litertal (t.ex. NUMBER och STRING) och andra symboler (operatorer och avgränsare, OP). Whitespace-tecken (andra än logiska radavslutare, som diskuterats tidigare) är inte tokens, utan används för att avgränsa tokens. Vid tvetydighet utgörs en token av den längsta möjliga sträng som utgör en legal token, läst från vänster till höger.

2.3. Namn (identifierare och nyckelord)

NAME-tokens representerar identifierare, nyckelord och mjuka nyckelord.

Inom ASCII-området (U+0001..U+007F) omfattar de giltiga tecknen för namn stora och små bokstäver (A-Z och a-z), understrecket _ och, med undantag för det första tecknet, siffrorna 0 till 9.

Namnen måste innehålla minst ett tecken, men har ingen övre längdgräns. Versaler är av betydelse.

Förutom A-Z, a-z, _ och 0-9 kan namn också använda ”bokstavs-liknande” och ”sifferliknande” tecken utanför ASCII-området, enligt nedan.

Alla identifierare konverteras till normalization form NFKC under parsing; jämförelse av identifierare baseras på NFKC.

Formellt sett måste det första tecknet i en normaliserad identifierare tillhöra uppsättningen id_start, som är en förening av:

• Unicode-kategori <Lu> - versaler (inkluderar A till Z)

• Unicode-kategori <Ll> - gemena bokstäver (inkluderar a till z)

• Unicode-kategori <Lt> - stora bokstäver

• Unicode-kategori <Lm> - modifieringsbokstäver

• Unicode-kategori <Lo> - andra bokstäver

• Unicode-kategori <Nl> - bokstavsnummer

• {"_"} - understrykningstecken

• <Other_ID_Start> - en explicit uppsättning tecken i PropList.txt för att stödja bakåtkompatibilitet

De återstående tecknen måste tillhöra uppsättningen id_continue, som är en förening av:

• alla tecken i id_start

• Unicode-kategori <Nd> - decimala tal (inkluderar 0 till 9)

• Unicode-kategori <Pc> - anslutande skiljetecken

• Unicode-kategori <Mn> - tecken utan mellanrum

• Unicode-kategori <Mc> - avstånd kombinerande tecken

• <Other_ID_Continue> - en annan explicit uppsättning tecken i PropList.txt för att stödja bakåtkompatibilitet

Unicode-kategorier använder den version av Unicode Character Database som ingår i modulen unicodedata.

Dessa uppsättningar är baserade på Unicode-standardens bilaga UAX-31. Se även PEP 3131 för ytterligare detaljer.

Ännu mer formellt beskrivs namn med hjälp av följande lexikala definitioner:

NAME:         xid_start xid_continue*
id_start:     <Lu> | <Ll> | <Lt> | <Lm> | <Lo> | <Nl> | "_" | <Other_ID_Start>
id_continue:  id_start | <Nd> | <Pc> | <Mn> | <Mc> | <Other_ID_Continue>
xid_start:    <all characters in id_start whose NFKC normalization is
               in (id_start xid_continue*)">
xid_continue: <all characters in id_continue whose NFKC normalization is
               in (id_continue*)">
identifier:   <NAME, except keywords>

En icke-normativ lista över alla giltiga identifieringstecken enligt Unicodes definition finns i filen DerivedCoreProperties.txt i Unicode Character Database.

2.3.1. Nyckelord

Följande namn används som reserverade ord, eller nyckelord i språket, och kan inte användas som vanliga identifierare. De måste stavas exakt som de skrivs här:

False      await      else       import     pass
None       break      except     in         raise
True       class      finally    is         return
and        continue   for        lambda     try
as         def        from       nonlocal   while
assert     del        global     not        with
async      elif       if         or         yield

2.3.2. Mjuka nyckelord

Tillagd i version 3.10.

Vissa namn är endast reserverade i specifika sammanhang. Dessa kallas för mjuka nyckelord:

• match, case och _, när de används i match-satsen.

• type, när den används i type-satsen.

Dessa fungerar syntaktiskt som nyckelord i sina specifika sammanhang, men denna åtskillnad görs på parsernivå, inte vid tokenisering.

Som mjuka nyckelord är det möjligt att använda dem i grammatiken samtidigt som kompatibiliteten med befintlig kod som använder dessa namn som identifierarnamn bibehålls.

Ändrad i version 3.12: typ är nu ett mjukt nyckelord.

2.3.3. Reserverade klasser av identifierare

Vissa klasser av identifierare (förutom nyckelord) har speciella betydelser. Dessa klasser identifieras av mönstren för inledande och avslutande understrykningstecken:

_*

Inte importerad av from module import *.

_

I ett case -mönster inom ett match -uttryck är _ ett mjukt nyckelord som betecknar ett jokertecken.

Separat gör den interaktiva tolken resultatet av den senaste utvärderingen tillgängligt i variabeln _. (Den lagras i modulen builtins, tillsammans med inbyggda funktioner som print)

På andra ställen är _ en vanlig identifierare. Det används ofta för att namnge ”speciella” objekt, men det är inte speciellt för Python självt.

Anteckning

Namnet _ används ofta i samband med internationalisering; se dokumentationen för modulen gettext för mer information om denna konvention.

Det används också ofta för oanvända variabler.

__*__

Systemdefinierade namn, informellt kända som ”dunder”-namn. Dessa namn definieras av tolken och dess implementation (inklusive standardbiblioteket). Nuvarande systemnamn diskuteras i avsnittet Särskilda metodnamn och på andra ställen. Fler kommer troligen att definieras i framtida versioner av Python. All användning av __*__-namn, i vilket sammanhang som helst, som inte följer explicit dokumenterad användning, är föremål för avbrott utan varning.

__*

Klass-privata namn. Namn i denna kategori, när de används inom ramen för en klassdefinition, skrivs om för att använda en manglad form för att undvika namnkollisioner mellan ”privata” attribut i bas- och härledda klasser. Se avsnittet Identifierare (namn).

2.4. Bokstäver

Literals är beteckningar för konstanta värden av vissa inbyggda typer.

När det gäller lexikal analys har Python sträng, bytes och numerisk literaler.

Andra ”literaler” betecknas lexikalt med nyckelord (None, True, False) och den speciella ellipsistoken (...).

2.5. Sträng- och Bytes-litteraler

Stränglitteraler är text som omges av enkla citattecken (') eller dubbla citattecken ("). Till exempel

"spam"
"ägg

Det citationstecken som används för att starta literalen avslutar den också, så en strängliteral kan bara innehålla det andra citationstecknet (utom med escape-sekvenser, se nedan). Till exempel

"Säg "hej", tack
"Gör inte så där!"

Med undantag för denna begränsning påverkar valet av citattecken (' eller ") inte hur den bokstavliga texten tolkas.

Inuti en strängliteral introducerar backsteget (\) en escape sequence, som har en speciell betydelse beroende på tecknet efter backsteget. Till exempel betecknar \" dubbla citattecken och avslutar inte strängen:

>>> print("Say \"Hello\" to everyone!")
Say "Hello" to everyone!

Se escape sequences nedan för en fullständig lista över sådana sekvenser och mer information.

2.5.1. Strängar med tre citattecken

Strängar kan också omslutas av matchande grupper om tre enkla eller dubbla citattecken. Dessa kallas i allmänhet triple-quoted strings:

"""Detta är en trippelciterad sträng."""

I trippelciterade bokstavstexter är oavkortade citattecken tillåtna (och behålls), förutom att tre oavkortade citattecken i rad avslutar bokstavstexten, om de är av samma typ (' eller ") som användes i början:

"""Den här strängen har "citattecken" inuti."""

Oavkortade nya linjer är också tillåtna och behålls:

'''Denna trippelciterade sträng
fortsätter på nästa rad.'''

2.5.2. Prefix för strängar

Stränglitteraler kan ha ett valfritt prefix som påverkar hur innehållet i litteralen analyseras, till exempel:

b"data"
f'{result=}'

De tillåtna prefixen är:

• b: Bytes literal

• r: Raw string

• f: Formaterad sträng litteral (”f-string”)

• t: Template string literal (”t-string”)

• u: Ingen effekt (tillåtet för bakåtkompatibilitet)

Se länkade avsnitt för mer information om varje typ.

Prefix är inte skiftlägeskänsliga (till exempel fungerar ’B’ på samma sätt som ’b’). Prefixet ’r’ kan kombineras med ’f’, ’t’ eller ’b’, så ’fr’, ’rf’, ’tr’, ’rt’, ’br’ och ’rb’ är också giltiga prefix.

Tillagd i version 3.3: Prefixet 'rb' för råa byteslitteraler har lagts till som en synonym till 'br'.

Stöd för unicode legacy literal (u'value') återinfördes för att förenkla underhållet av dubbla Python 2.x och 3.x kodbaser. Se PEP 414 för mer information.

2.5.3. Formell grammatik

Stränglitteraler, utom ”f-strings” och ”t-strings”, beskrivs av följande lexikala definitioner.

Dessa definitioner använder negativa lookaheads (!) för att ange att ett avslutande citattecken avslutar den bokstavliga sekvensen.

STRING:          [stringprefix] (stringcontent)
stringprefix:    <("r" | "u" | "b" | "br" | "rb"), case-insensitive>
stringcontent:
   | "'" ( !"'" stringitem)* "'"
   | '"' ( !'"' stringitem)* '"'
   | "'''" ( !"'''" longstringitem)* "'''"
   | '"""' ( !'"""' longstringitem)* '"""'
stringitem:      stringchar | stringescapeseq
stringchar:      <any source_character, except backslash and newline>
longstringitem:  stringitem | newline
stringescapeseq: "\" <any source_character>

Observera att som i alla lexikala definitioner är blanksteg betydelsefulla. I synnerhet måste prefixet (om det finns något) omedelbart följas av det inledande citatet.

2.5.4. Escape-sekvenser

Om inte prefixet ’r’ eller ’R’ förekommer tolkas escape-sekvenser i sträng- och byte-literaler enligt regler som liknar dem som används i Standard C. De escape-sekvenser som känns igen är:

Utrymningssekvens	Betydelse
\<newline>	Ignorerade slutet av raden
\\	Backslash
\'	Enkel offert
\"	Dubbelcitat
\a	ASCII Klocka (BEL)
\b	ASCII Backspace (BS)
\f	ASCII Formfeed (FF)
\n	ASCII radmatning (LF)
\r	ASCII vagnsretur (CR)
\t	ASCII Horisontell tabb (TAB)
\v	ASCII Vertikal tabb (VT)
\ooo	Oktal tecken
\xhh	Hexadecimalt tecken
\N{name}`	Namngivet Unicode-tecken
\uxxxx	Hexadecimal Unicode-tecken
\Uxxxxxxxx	Hexadecimal Unicode-tecken

2.5.4.1. Ignorerade slutet av raden

En backslash kan läggas till i slutet av en rad för att ignorera nystrecket:

>>> 'This string will not include \
... backslashes or newline characters.'
'This string will not include backslashes or newline characters.'

Samma resultat kan uppnås med hjälp av triple-quoted strings, eller parenteser och string literal concatenation.

2.5.4.2. Försvunna karaktärer

För att inkludera en backsteg i en Python-sträng som inte är raw måste den dubbleras. Escape-sekvensen \\ betecknar ett enda backstegstecken:

>>> print('C:\\Program Files')
C:\Program Files

På samma sätt betecknar sekvenserna \' och \" enkla respektive dubbla citattecken:

>>> print('\' and \"')
' and "

2.5.4.3. Oktal tecken

Sekvensen \ooo betecknar ett tecken med oktalvärdet (bas 8) ooo:

>>> '\120'
'P'

Upp till tre oktala siffror (0 till 7) accepteras.

I en byteslitteral betyder tecken en byte med det angivna värdet. I en stränglitteral betyder det ett Unicode-tecken med det angivna värdet.

Ändrad i version 3.11: Oktala escapes med ett värde större än 0o377 (255) ger en DeprecationWarning.

Ändrad i version 3.12: Oktala escapes med värde större än 0o377 (255) ger en SyntaxWarning. I en framtida Python-version kommer de att ge upphov till ett SyntaxError.

2.5.4.4. Hexadecimalt tecken

Sekvensen \xhh betecknar ett tecken med hex (bas 16)-värdet hh:

>>> '\x50'
'P'

Till skillnad från i Standard C krävs exakt två hexadecimala siffror.

I en byteslitteral betyder tecken en byte med det angivna värdet. I en stränglitteral betyder det ett Unicode-tecken med det angivna värdet.

2.5.4.5. Namngivet Unicode-tecken

Sekvensen \N{name} betecknar ett Unicode-tecken med det angivna namnet:

>>> '\N{LATIN CAPITAL LETTER P}'
'P'
>>> '\N{SNAKE}'
'🐍'

Denna sekvens kan inte förekomma i bytes literals.

Ändrad i version 3.3: Stöd för namnalias har lagts till.

2.5.4.6. Hexadecimal Unicode-tecken

Dessa sekvenser \uxxxx och \Uxxxxxxxx betecknar Unicode-tecknet med det angivna hex (bas 16)-värdet. Exakt fyra siffror krävs för \u; exakt åtta siffror krävs för U. Det senare kan koda vilket Unicode-tecken som helst.

>>> '\u1234'
'ሴ'
>>> '\U0001f40d'
'🐍'

Dessa sekvenser kan inte förekomma i bytes literals.

2.5.4.7. Oigenkända escape-sekvenser

Till skillnad från Standard C lämnas alla oigenkända escapesekvenser kvar i strängen oförändrade, dvs. backslash lämnas kvar i resultatet:

>>> print('\q')
\q
>>> list('\q')
['\\', 'q']

Observera att för byte-litteraler faller de escapesekvenser som endast känns igen i sträng-litteraler (\N..., \u..., U...) i kategorin oigenkända escapes.

Ändrad i version 3.6: Oigenkända escape-sekvenser ger upphov till en DeprecationWarning.

Ändrad i version 3.12: Oigenkända escape-sekvenser ger upphov till en SyntaxWarning. I en framtida Python-version kommer de att ge upphov till ett SyntaxError.

2.5.5. Bytes-litteraler

Bytes-literaler har alltid prefixet ’b’ eller ’B’; de producerar en instans av typen bytes istället för typen str. De får endast innehålla ASCII-tecken; byte med ett numeriskt värde på 128 eller högre måste uttryckas med escape-sekvenser (vanligtvis Hexadecimalt tecken eller Oktal tecken):

>>> b'\x89PNG\r\n\x1a\n'
b'\x89PNG\r\n\x1a\n'
>>> list(b'\x89PNG\r\n\x1a\n')
[137, 80, 78, 71, 13, 10, 26, 10]

På samma sätt måste en nollbyte uttryckas med hjälp av en escape-sekvens (typiskt ”0” eller ”x00”).

2.5.6. Råa stränglitteraler

Både sträng- och byte-literaler kan valfritt föregås av bokstaven ’r’ eller ’R’; sådana konstruktioner kallas rå strängliteraler respektive raw bytes literals och behandlar bakstreck som bokstavliga tecken. Som ett resultat behandlas escapeseekvenser inte på något speciellt sätt i råa strängliteraler:

>>> r'\d{4}-\d{2}-\d{2}'
'\\d{4}-\\d{2}-\\d{2}'

Även i en rå bokstav kan citattecken undkomma med ett backslash, men backslash kvarstår i resultatet; till exempel är r"\"" en giltig stränglitteral som består av två tecken: ett backslash och ett dubbelt citattecken; r"\" är inte en giltig stränglitteral (även en rå sträng kan inte sluta med ett udda antal backslash). Specifikt kan en rå bokstav inte sluta med ett enda backslash (eftersom backslash skulle undkomma det följande citattecknet). Observera också att ett enkelt backslash följt av en ny rad tolkas som att de två tecknen är en del av den bokstavliga texten, inte som en radfortsättning.

2.5.7. f-strängar

Tillagd i version 3.6.

A formatted string literal eller f-string är en strängliteral som föregås av ’f’ eller ’F’. Dessa strängar kan innehålla ersättningsfält, som är uttryck avgränsade av klamrar {}. Vid andra strängliteraler har alltid ett konstant värde, är formaterade strängar egentligen uttryck som utvärderas vid körning.

Escape-sekvenser avkodas på samma sätt som vanliga stränglitteraler (utom när en literal också markeras som en rå sträng). Efter avkodning är grammatiken för strängens innehåll följande:

f_string:          (literal_char | "{{" | "}}" | replacement_field)*
replacement_field: "{" f_expression ["="] ["!" conversion] [":" format_spec] "}"
f_expression:      (conditional_expression | "*" or_expr)
                     ("," conditional_expression | "," "*" or_expr)* [","]
                   | yield_expression
conversion:        "s" | "r" | "a"
format_spec:       (literal_char | replacement_field)*
literal_char:      <any code point except "{", "}" or NULL>

De delar av strängen som står utanför hakparenteser behandlas bokstavligt, förutom att eventuella dubbla hakparenteser '{{' eller '}}' ersätts med motsvarande enkla hakparentes. En enkel öppnande hakparentes '{' markerar ett ersättningsfält, som börjar med ett Python-uttryck. För att visa både uttryckstexten och dess värde efter utvärdering (användbart vid felsökning), kan ett likhetstecken '=' läggas till efter uttrycket. Ett konverteringsfält, som inleds med ett utropstecken '!' kan följa. En formatspecifikator kan också läggas till, inledd med ett kolon ':'. Ett ersättningsfält avslutas med en avslutande hakparentes '}'.

Uttryck i formaterade stränglitteraler behandlas som vanliga Python-uttryck omgivna av parenteser, med några få undantag. Ett tomt uttryck är inte tillåtet, och både lambda och tilldelningsuttryck := måste omges av uttryckliga parenteser. Varje uttryck utvärderas i det sammanhang där den formaterade strängbokstaven förekommer, i ordning från vänster till höger. Ersättningsuttryck kan innehålla nya rader i både enkelciterade och trippelciterade f-strängar och de kan innehålla kommentarer. Allt som kommer efter en # inuti ett ersättningsfält är en kommentar (även avslutande parenteser och citattecken). I så fall måste ersättningsfält stängas på en annan rad.

>>> f"abc{a # This is a comment }"
... + 3}"
'abc5'

Ändrad i version 3.7: Före Python 3.7 var ett await-uttryck och förståelser som innehöll en async for-klausul olagliga i uttryck i formaterade stränglitteraler på grund av ett problem med implementeringen.

Ändrad i version 3.12: Före Python 3.12 var kommentarer inte tillåtna i ersättningsfält för f-string.

När likhetstecknet '=' anges, kommer utdata att innehålla uttryckstexten, '=' och det utvärderade värdet. Mellanrum efter den inledande parentesen '{', inom uttrycket och efter '=' behålls i utdata. Som standard orsakar '=' att repr() av uttrycket tillhandahålls, såvida inte ett format har angetts. När ett format är specificerat är standardvärdet str() av uttrycket om inte en konvertering '!r' är deklarerad.

Tillagd i version 3.8: Likhetstecknet '='.

Om en konvertering anges, konverteras resultatet av utvärderingen av uttrycket innan det formateras. Konvertering '!s' anropar str() på resultatet, '!r' anropar repr(), och '!a' anropar ascii().

Resultatet formateras sedan med hjälp av protokollet format(). Formatspecificeraren skickas till __format__()-metoden för uttrycket eller konverteringsresultatet. En tom sträng skickas när formatspecificeraren utelämnas. Det formaterade resultatet ingår då i slutvärdet för hela strängen.

Formatspecifikatorer på högsta nivån kan innehålla nästlade ersättningsfält. Dessa nästlade fält kan inkludera sina egna konverteringsfält och formatspecifikatorer, men kan inte inkludera mer djupt nästlade ersättningsfält. Den formatspecifikator mini-språk är densamma som används av str.format()-metoden.

Formaterade stränglitteraler kan konkateneras, men ersättningsfält kan inte delas upp mellan litteraler.

Några exempel på formaterade stränglitteraler:

>>> name = "Fred"
>>> f"He said his name is {name!r}."
"He said his name is 'Fred'."
>>> f"He said his name is {repr(name)}."  # repr() is equivalent to !r
"He said his name is 'Fred'."
>>> width = 10
>>> precision = 4
>>> value = decimal.Decimal("12.34567")
>>> f"result: {value:{width}.{precision}}"  # nested fields
'result:      12.35'
>>> today = datetime(year=2017, month=1, day=27)
>>> f"{today:%B %d, %Y}"  # using date format specifier
'January 27, 2017'
>>> f"{today=:%B %d, %Y}" # using date format specifier and debugging
'today=January 27, 2017'
>>> number = 1024
>>> f"{number:#0x}"  # using integer format specifier
'0x400'
>>> foo = "bar"
>>> f"{ foo = }" # preserves whitespace
" foo = 'bar'"
>>> line = "The mill's closed"
>>> f"{line = }"
'line = "The mill\'s closed"'
>>> f"{line = :20}"
"line = The mill's closed   "
>>> f"{line = !r:20}"
'line = "The mill\'s closed" '

Det är tillåtet att återanvända den yttre citattypen f-string i ett ersättningsfält:

>>> a = dict(x=2)
>>> f"abc {a["x"]} def"
'abc 2 def'

Ändrad i version 3.12: Före Python 3.12 var det inte möjligt att återanvända samma citattyp för den yttre f-strängen i ett ersättningsfält.

Backslash är också tillåtet i ersättningsfält och utvärderas på samma sätt som i alla andra sammanhang:

>>> a = ["a", "b", "c"]
>>> print(f"List a contains:\n{"\n".join(a)}")
List a contains:
a
b
c

Ändrad i version 3.12: Före Python 3.12 var backslash inte tillåtet inuti ett ersättningsfält för f-strängar.

Formaterade stränglitteraler kan inte användas som docstrings, även om de inte innehåller uttryck.

>>> def foo():
...     f"Not a docstring"
...
>>> foo.__doc__ is None
True

Se även PEP 498 för förslaget som lade till formaterade stränglitteraler, och str.format(), som använder en relaterad formatsträngmekanism.

2.5.8. t-strängar

Tillagd i version 3.14.

A mallsträngkonstant eller t-sträng är en strängkonstant som föregås av ’t’ eller ’T’. Dessa strängar följer samma syntax och utvärderingsregler som formaterade strängkonstanter, med följande skillnader:

• I stället för att utvärderas till ett str-objekt utvärderas mallsträngkonstanter till ett string.templatelib.Template-objekt.

• Protokollet format() används inte. Istället skickas formatangivaren och konverteringar (om några) till ett nytt Interpolation-objekt som skapas för varje utvärderat uttryck. Det är upp till koden som bearbetar det resulterande Template-objektet att bestämma hur formatspecifikatorer och konverteringar ska hanteras.

• Formatspecifikatorer som innehåller kapslade ersättningsfält utvärderas omedelbart innan de skickas till objektet Interpolation. Till exempel kommer en interpolering av formen {amount:.{precision}f} att utvärdera det inre uttrycket {precision} för att bestämma värdet på attributet format_spec. Om precision vore 2, skulle det resulterande formatangivaren bli '.2f'.

• När likhetstecknet '=' anges i ett interpolationsuttryck, läggs uttryckets text till den bokstavliga sträng som föregår den relevanta interpolationen. Detta inkluderar likhetstecknet och eventuella omgivande blanktecken. Instansen Interpolation för uttrycket skapas som vanligt, förutom att conversion som standard sätts till ’r’ (repr()). Om en explicit konvertering eller formatangivelse anges, åsidosätts standardbeteendet.

2.6. Numeriska bokstäver

NUMBER-tokens representerar numeriska literaler, av vilka det finns tre typer: heltal, flyttal och imaginära tal.

NUMBER: integer | floatnumber | imagnumber

Det numeriska värdet för en numerisk litteral är detsamma som om den hade skickats som en sträng till klasskonstruktören int, float eller complex. Observera att inte alla giltiga indata för dessa konstruktörer också är giltiga literaler.

Numeriska bokstavstecken innehåller inte något tecken; en fras som -1 är egentligen ett uttryck som består av den unära operatorn - och bokstavstecknet 1.

2.6.1. Heltalslitteraler

Heltalslitteraler betecknar hela tal. Till exempel:

7
3
2147483647

Det finns ingen begränsning för längden på heltalslitteraler förutom vad som kan lagras i tillgängligt minne:

7922816251426433759354395033679228162514264337593543950336

Underscores kan användas för att gruppera siffror för ökad läsbarhet, och ignoreras för att bestämma det numeriska värdet av literalen. Till exempel är följande literaler likvärdiga:

100_000_000_000
100000000000
1_00_00_00_00_000

Underscores kan endast förekomma mellan siffror. Till exempel är _123, 321_ och 123__321 inte giltiga bokstavstecken.

Heltal kan anges i binär (bas 2), oktal (bas 8) eller hexadecimal (bas 16) med hjälp av prefixen 0b, 0o respektive 0x. De hexadecimala siffrorna 10 till 15 representeras av bokstäverna A-F, utan hänsyn till skiftlägesskillnader. Till exempel:

0b100110111
0b_1110_0101
0o177
0o377
0xdeadbeef
0xDöd_Beef

Ett understreck kan följa basspecificeraren. Till exempel är 0x_1f en giltig bokstav, men 0_x1f och 0x__1f är det inte.

Ledande nollor i ett decimaltal som inte är noll är inte tillåtna. Till exempel är 0123 inte en giltig bokstav. Detta är för disambiguering med C-stil oktala literaler, som Python använde före version 3.0.

Formellt beskrivs heltalslitteraler med följande lexikala definitioner:

integer:      decinteger | bininteger | octinteger | hexinteger | zerointeger
decinteger:   nonzerodigit (["_"] digit)*
bininteger:   "0" ("b" | "B") (["_"] bindigit)+
octinteger:   "0" ("o" | "O") (["_"] octdigit)+
hexinteger:   "0" ("x" | "X") (["_"] hexdigit)+
zerointeger:  "0"+ (["_"] "0")*
nonzerodigit: "1"..."9"
digit:        "0"..."9"
bindigit:     "0" | "1"
octdigit:     "0"..."7"
hexdigit:     digit | "a"..."f" | "A"..."F"

Ändrad i version 3.6: Underscores är nu tillåtna för grupperingsändamål i literals.

2.6.2. Flyttalslitteraler

Flyttal (float), t.ex. 3,14 eller 1,5, betecknar approximationer av reella tal.

De består av integer och fraction delar, var och en sammansatt av decimalsiffror. Delarna är åtskilda av ett decimaltecken, .:

2.71828
4.0

Till skillnad från i heltalslitteraler är inledande nollor tillåtna i de numeriska delarna. Till exempel är 077.010 lagligt och betecknar samma tal som 77.10.

Precis som i heltalslitteraler kan enkla understrykningar förekomma mellan siffrorna för att underlätta läsbarheten:

96_485.332_123
3.14_15_93

Endera av dessa delar, men inte båda, kan vara tomma. Till exempel:

10.  # (motsvarande 10,0)
.001 # (motsvarar 0,001)

Eventuellt kan heltalet och bråket följas av en exponent: bokstaven e eller E, följt av ett valfritt tecken, + eller -, och ett tal i samma format som heltalet och bråket. Bokstaven e eller E representerar ”gånger tio upphöjt till en potens av”:

1.0e3 # (representerar 1,0×10³, eller 1000,0)
1.166e-5 # (representerar 1,166×10-⁵, eller 0,00001166)
6.02214076e+23 # (representerar 6,02214076×10²³, eller 602214076000000000000000.)

I flyttal med endast heltals- och exponentdelar kan decimaltecknet utelämnas:

1e3 # (motsvarande 1.e3 och 1.0e3)
0e0 # (motsvarar 0.)

Formellt beskrivs flyttalslitteraler med följande lexikala definitioner:

floatnumber:
   | digitpart "." [digitpart] [exponent]
   | "." digitpart [exponent]
   | digitpart exponent
digitpart: digit (["_"] digit)*
exponent:  ("e" | "E") ["+" | "-"] digitpart

Ändrad i version 3.6: Underscores är nu tillåtna för grupperingsändamål i literals.

2.6.3. Imaginära bokstäver

Python har komplexa tal-objekt, men inga komplexa litteraler. Istället betecknar imaginära literaler komplexa tal med en reell del på noll.

I matematik skrivs till exempel det komplexa talet 3+4,2i som det reella talet 3 adderat till det imaginära talet 4,2i. Python använder en liknande syntax, förutom att den imaginära enheten skrivs som j i stället för i:

3+4.2j

Detta är ett uttryck som består av heltal 3, operator ’+’ och imaginärt tal 4.2j. Eftersom detta är tre separata token är det tillåtet med blanktecken mellan dem:

3 + 4.2j

Inga blanksteg tillåts inom varje token. I synnerhet får suffixet ”j” inte separeras från siffran före det.

Talet före j har samma syntax som en flyttalslitteral. Följande är alltså giltiga imaginära literaler:

4.2j
3.14j
10.j
.001j
1e100j
3.14e-10j
3.14_15_93j

Till skillnad från i en flyttalslitteral kan decimaltecknet utelämnas om det imaginära talet bara har en heltalsdel. Talet utvärderas fortfarande som ett flyttal, inte som ett heltal:

10j
0j
1000000000000000000000000j # motsvarande 1e+24j

Suffixet j är okänsligt för stora och små bokstäver. Det betyder att du kan använda J istället för:

3.14J # motsvarande 3.14j

Formellt beskrivs imaginära literaler med följande lexikala definition:

imagnumber: (floatnumber | digitpart) ("j" | "J")

2.7. Operatorer

Följande symboler är operatorer:

+ - * ** / // % @
<< >> & | ^ ~ :=
< > <= >= == !=

2.8. Avgränsningstecken

Följande tokens fungerar som avgränsare i grammatiken:

( ) [ ] { }
, : !       . ; @ =

Perioden kan också förekomma i flyttals- och imaginära literaler.

En sekvens av tre punkter har en särskild betydelse som en Ellipsis-litteral:

...

Följande förstärkta tilldelningsoperatorer fungerar lexikalt som avgränsare, men utför också en operation:

-> += -= *= /= //= %=
@= &= |= ^= >>= <<= **=

Följande skrivande ASCII-tecken har särskild betydelse som del av andra tokens eller är på annat sätt betydelsefulla för den lexikala analysatorn:

' " # \

Följande skrivande ASCII-tecken används inte i Python. Deras förekomst utanför stränglitteraler och kommentarer är ett ovillkorligt fel:

$ ?       `