2. Análise léxica¶
Um programa Python é lido por um analisador. A entrada para o analisador é um fluxo de tokens, gerados pelo analisador léxico (também conhecido como tokenizador). Este capítulo descreve como o analisador léxico produz esses tokens.
O analisador léxico determina a codificação do texto do programa (UTF-8 por padrão), e o decodifica em caracteres da fonte. Se o texto não puder ser decodificado, uma SyntaxError é levantada.
Em seguida, o analisador léxico usa os caracteres da fonte para gerar um fluxo de tokens. Geralmente, o tipo de um token gerado depende do próximo caracter da fonte a ser processado. Além disso, outros comportamentos especiais do analisador também dependem do primeiro caracter da fonte que ainda não foi processado. A seguinte tabela é um resumo desses caracteres da fonte, com links para seções que contém mais informação.
Caractere |
Token seguinte (ou outra documentação relevante) |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.1. Estrutura das linhas¶
Um programa Python é dividido em uma série de linhas lógicas.
2.1.1. Linhas lógicas¶
O fim de uma linha lógica é representado pelo token NEWLINE. As instruções não podem cruzar os limites da linha lógica, exceto onde NEWLINE for permitido pela sintaxe (por exemplo, entre as instruções de instruções compostas). Uma linha lógica é construída a partir de uma ou mais linhas físicas seguindo as regras explícitas ou implícitas que juntam as linhas.
2.1.2. Linhas físicas¶
Uma linha física é uma sequência de caracteres terminada por uma das seguintes sequências de fim de linha:
o formulário Unix usando ASCII LF (avanço de linha),
o formulário do Windows usando a sequência ASCII CR LF (retorno seguido de avanço de linha),
o formato ‘Classic Mac OS’ usando o caractere ASCII CR (retorno).
Independentemente da plataforma, cada uma dessas sequências é substituída por um único caractere ASCII LF (avanço de linha). (Isso é feito até mesmo dentro de literais de string.) Cada linha pode usar qualquer uma das sequências; elas não precisam ser consistentes dentro de um arquivo.
O fim da entrada também serve como um terminador implícito para a linha física final.
Formalmente:
newline: <ASCII LF> | <ASCII CR> <ASCII LF> | <ASCII CR>
2.1.4. Declarações de codificação¶
Se um comentário na primeira ou segunda linha de um script Python corresponde com a expressão regular coding[=:]\s*([-\w.]+), esse comentário é processado com uma declaração de codificação; o primeiro grupo dessa expressão indica a codificação do arquivo do código-fonte. A declaração de codificação deve aparecer em uma linha exclusiva para tal. Se está na segunda linha, a primeira linha também deve ser uma linha somente com comentário. As formas recomendadas de uma declaração de codificação são:
# -*- coding: <nome-codificação> -*-
que é reconhecido também por GNU Emacs, e
# vim:fileencoding=<nome-codificação>
que é reconhecido pelo VIM de Bram Moolenaar.
Se nenhuma codificação é declarada, a codificação padrão é UTF-8. Se a codificação implícita ou explícita de um arquivo é UTF-8, uma marca inicial de ordem de byte UTF-8 (b'\xef\xbb\xbf') será ignorada em vez de ser um erro de sintaxe.
Se uma codificação é declarada, o nome da codificação deve ser reconhecida pelo Python (veja Standard Encodings). A codificação é usada por toda análise léxica, incluindo literais strings, comment and identificadores.
Toda a análise lexical, incluindo literais de string, comentários e identificadores, funciona em texto Unicode decodificado usando a codificação de origem. Qualquer ponto de código Unicode, exceto o caractere de controle NUL, pode aparecer no código-fonte Python.
source_character: <any Unicode code point, except NUL>
2.1.5. Junção de linha explícita¶
Duas ou mais linhas físicas podem ser juntadas em linhas lógicas usando o caractere contrabarra (\) da seguinte forma: quando uma linha física termina com uma contrabarra que não é parte da uma literal string ou comentário, ela é juntada com a linha seguinte formando uma única linha lógica, removendo a contrabarra e o caractere de fim de linha seguinte. Por exemplo:
if 1900 < year < 2100 and 1 <= month <= 12 \
and 1 <= day <= 31 and 0 <= hour < 24 \
and 0 <= minute < 60 and 0 <= second < 60: # Parece ser uma data válida
return 1
Uma linha terminada em uma contrabarra não pode conter um comentário. Uma barra invertida não continua um comentário. Uma contrabarra não continua um token, exceto para strings literais (ou seja, tokens diferentes de strings literais não podem ser divididos em linhas físicas usando uma contrabarra). Uma contrabarra é ilegal em qualquer outro lugar em uma linha fora de uma string literal.
2.1.6. Junção de linha implícita¶
Expressões entre parênteses, colchetes ou chaves podem ser quebradas em mais de uma linha física sem a necessidade do uso de contrabarras. Por exemplo:
month_names = ['Januari', 'Februari', 'Maart', # Estes são os
'April', 'Mei', 'Juni', # nomes holandeses
'Juli', 'Augustus', 'September', # para os meses
'Oktober', 'November', 'December'] # do ano
Linhas continuadas implicitamente podem conter comentários. O recuo das linhas de continuação não é importante. Linhas de continuação em branco são permitidas. Não há token NEWLINE entre linhas de continuação implícitas. Linhas continuadas implicitamente também podem ocorrer dentro de strings com aspas triplas (veja abaixo); nesse caso, eles não podem conter comentários.
2.1.7. Linhas em branco¶
Uma linha lógica que contém apenas espaços, tabulações, quebras de página e possivelmente um comentário é ignorada (ou seja, nenhum token NEWLINE é gerado). Durante a entrada interativa de instruções, o tratamento de uma linha em branco pode diferir dependendo da implementação do interpretador. No interpretador interativo padrão, uma linha lógica totalmente em branco (ou seja, uma que não contenha nem mesmo espaço em branco ou um comentário) encerra uma instrução multilinha.
2.1.8. Indentação¶
O espaço em branco (espaços e tabulações) no início de uma linha lógica é usado para calcular o nível de indentação da linha, que por sua vez é usado para determinar o agrupamento de instruções.
As tabulações são substituídas (da esquerda para a direita) por um a oito espaços, de modo que o número total de caracteres até e incluindo a substituição seja um múltiplo de oito (essa é intencionalmente a mesma regra usada pelo Unix). O número total de espaços que precedem o primeiro caractere não em branco determina o recuo da linha. O recuo não pode ser dividido em várias linhas físicas usando contrabarra; o espaço em branco até a primeira contrabarra determina a indentação.
A indentação é rejeitada como inconsistente se um arquivo de origem mistura tabulações e espaços de uma forma que torna o significado dependente do valor de uma tabulação em espaços; uma exceção TabError é levantada nesse caso.
Nota de compatibilidade entre plataformas: devido à natureza dos editores de texto em plataformas não-UNIX, não é aconselhável usar uma mistura de espaços e tabulações para o recuo em um único arquivo de origem. Deve-se notar também que diferentes plataformas podem limitar explicitamente o nível máximo de indentação.
Um caractere de quebra de página pode estar presente no início da linha; ele será ignorado para os cálculos de indentação acima. Os caracteres de quebra de página que ocorrem em outro lugar além do espaço em branco inicial têm um efeito indefinido (por exemplo, eles podem redefinir a contagem de espaços para zero).
Os níveis de indentação das linhas consecutivas são usados para gerar tokens INDENT e DEDENT, usando uma pilha, como segue.
Antes da leitura da primeira linha do arquivo, um único zero é colocado na pilha; esse valor nunca mais será exibido. Os números colocados na pilha sempre aumentarão estritamente de baixo para cima. No início de cada linha lógica, o nível de indentação da linha é comparado ao topo da pilha. Se for igual, nada acontece. Se for maior, ele é colocado na pilha e é gerado um token INDENT. Se for menor, deve ser um dos números que aparecem na pilha; todos os números maiores na pilha são retirados e, para cada número retirado, é gerado um token DEDENT. Ao final do arquivo, um token DEDENT é gerado para cada número restante na pilha que seja maior que zero.
Aqui está um exemplo de um trecho de código Python indentado corretamente (embora confuso):
def perm(l):
# Calcula a lista de todas as permutações de l
if len(l) <= 1:
return [l]
r = []
for i in range(len(l)):
s = l[:i] + l[i+1:]
p = perm(s)
for x in p:
r.append(l[i:i+1] + x)
return r
O exemplo a seguir mostra vários erros de indentação:
def perm(l): # erro: primeira linha indentada
for i in range(len(l)): # erro: não indentada
s = l[:i] + l[i+1:]
p = perm(l[:i] + l[i+1:]) # erro: indentação inesperada
for x in p:
r.append(l[i:i+1] + x)
return r # erro: desindentação inconsistente
(Na verdade, os três primeiros erros são detectados pelo analisador sintático; apenas o último erro é encontrado pelo analisador léxico — o recuo de não corresponde a um nível retirado da pilha.)
2.1.9. Espaços em branco entre tokens¶
Exceto no início de uma linha lógica ou em literais de string, os caracteres de espaço em branco (espaço, tabulação e avanço de página) podem ser usados indistintamente para separar tokens:
whitespace: ' ' | tab | formfeed
O espaço em branco é necessário entre dois tokens somente se sua concatenação puder ser interpretada como um token diferente (por exemplo, ab é um token, mas a b são dois tokens). Entretanto, +a e + a produzem dois tokens, + e a, pois +a não é um token válido.
2.1.10. Marcador de fim¶
No final da entrada não interativa, o analisador léxico gera um token ENDMARKER.
2.2. Outros tokens¶
Além de NEWLINE, INDENT e DEDENT, existem as seguintes categorias de tokens: identificadores, palavras-chave (NAME), literais (como NUMBER e STRING) e outros símbolos (operadores e delimitadores, OP). Caracteres de espaço em branco (exceto os terminadores lógicos de linha, discutidos anteriormente) não são tokens, mas servem para delimitar tokens. Onde há ambiguidade, um token compreende a string mais longa possível que forma um token legal, quando lido da esquerda para a direita.
2.3. Nomes (identificadores e palavras reservadas)¶
Tokens NAME representam identificadores, palavras reservadas e palavras reservadas contextuais.
Nomes são compostos dos seguintes caracteres:
letras maiúsculas e minúsculas (
A-Zea-z),o sublinhado (
_),dígitos (
0a9), que não podem aparecer como o primeiro caractere, ecaracteres não ASCII. Nomes válidos podem conter apenas caracteres “semelhantes a letras” e “semelhantes a dígitos”; consulte Caracteres não ASCII em nomes para obter detalhes.
Os nomes devem conter pelo menos um caractere, mas não há limite máximo de tamanho. Maiúsculas e minúsculas são relevantes.
Formalmente, nomes são descritos pelas seguintes definições léxicas:
NAME:name_startname_continue* name_start: "a"..."z" | "A"..."Z" | "_" | <non-ASCII character> name_continue: name_start | "0"..."9" identifier: <NAME, except keywords>
Observe que nem todos os nomes correspondentes a esta gramática são válidos; consulte Caracteres não ASCII em nomes para obter detalhes.
2.3.1. Palavras reservadas¶
Os nomes a seguir são usados como palavras reservadas e não podem ser usados como identificadores comuns. Eles devem ser escritos exatamente como estão escritos aqui:
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. Palavras reservadas contextuais¶
Adicionado na versão 3.10.
Alguns nomes são reservados apenas em contextos específicos. São conhecidos como palavras reservadas contextuais:
Elas agem sintaticamente como palavra reservada em seus contextos específicos, mas essa distinção é feita no nível do analisador sintático, não na tokenização.
Como palavras reservadas contextuais, seu uso na gramática é possível preservando a compatibilidade com o código existente que usa esses nomes como identificadores.
Alterado na versão 3.12: type é agora uma palavra reservada contextual.
2.3.3. Classes reservadas de identificadores¶
Certas classes de identificadores (além de palavras reservadas) possuem significados especiais. Essas classes são identificadas pelos padrões de caracteres de sublinhado iniciais e finais:
_*Não importado por
from module import *._Em um padrão
casede uma instruçãomatch,_é uma palavra reservada contextual que denota um curinga.Isoladamente, o interpretador interativo disponibiliza o resultado da última avaliação na variável
_. (Ele é armazenado no módulobuiltins, juntamente com funções embutidas comoprint.)Em outros lugares,
_é um identificador comum. Muitas vezes é usado para nomear itens “especiais”, mas não é especial para o Python em si.Nota
O nome
_é frequentemente usado em conjunto com internacionalização; consulte a documentação do módulogettextpara obter mais informações sobre esta convenção.Também é comumente usado para variáveis não utilizadas.
__*__Nomes definidos pelo sistema, informalmente conhecidos como nomes “dunder”. Esses nomes e suas implementações são definidos pelo interpretador (incluindo a biblioteca padrão). Os nomes de sistema atuais são discutidos na seção Nomes de métodos especiais e em outros lugares. Provavelmente mais nomes serão definidos em versões futuras do Python. Qualquer uso de nomes
__*__, em qualquer contexto, que não siga o uso explicitamente documentado, está sujeito a quebra sem aviso prévio.__*Nomes de classes privadas. Os nomes nesta categoria, quando usados no contexto de uma definição de classe, são reescritos para usar uma forma desfigurada para ajudar a evitar conflitos de nomes entre atributos “privados” de classes base e derivadas. Consulte a seção Identificadores (Nomes).
2.3.4. Caracteres não ASCII em nomes¶
Nomes que contêm caracteres não ASCII precisam de normalização e validação adicionais além das regras e gramática explicadas acima. Por exemplo, ř_1, 蛇 ou साँप são nomes válidos, mas r〰2, € ou 🐍 não são.
Esta seção explica as exatas regras.
Todos os nomes são convertidos para a forma de normalização NFKC durante a análise sintática. Isso significa que, por exemplo, algumas variantes tipográficas de caracteres são convertidas para sua forma “básica”. Por exemplo, fiⁿₐˡᵢᶻₐᵗᵢᵒₙ é normalizado para finalization, então o Python os trata como o mesmo nome:
>>> fiⁿₐˡᵢᶻₐᵗᵢᵒₙ = 3
>>> finalization
3
Nota
A normalização é feita apenas no nível léxico. Funções de tempo de execução que recebem nomes como strings geralmente não normalizam seus argumentos. Por exemplo, a variável definida acima é acessível em tempo de execução no dicionário globals() como globals()["finalization"], mas não como globals()["fiⁿₐˡᵢᶻₐᵗᵢᵒₙ"].
Assim como os nomes que usam apenas ASCII devem conter somente letras, dígitos e o sublinhado, e não podem começar com um dígito, um nome válido deve começar com um caractere do conjunto “semelhante a letras” xid_start, e os caracteres restantes devem estar no conjunto “semelhante a letras e dígitos” xid_continue.
Esses conjuntos são baseados nos conjuntos XID_Start e XID_Continue, conforme definidos pelo anexo UAX-31 do padrão Unicode. O xid_start do Python inclui adicionalmente o sublinhado (_). Observe que o Python não está necessariamente em conformidade com o UAX-31.
Uma lista não normativa de caracteres nos conjuntos XID_Start e XID_Continue, conforme definidos pelo Unicode, está disponível no arquivo DerivedCoreProperties.txt no Banco de Dados de Caracteres Unicode. Para referência, as regras de construção para os conjuntos xid_* são apresentadas abaixo.
O conjunto id_start é definido como a união de:
Categoria Unicode
<Lu>- letras maiúsculas (incluiAaZ)Categoria Unicode
<Ll>- letras minúsculas (incluiaaz)Categoria Unicode
<Lt>- letras em titlecase (coloca em maiúsculo a primeira letra de cada palavra principal)Categoria Unicode
<Lm>- letras modificadorasCategoria Unicode
<Lo>- outras letrasCategoria Unicode
<Nl>- números de letras{
"_"} - o underscore (sublinhado)<Other_ID_Start>- um conjunto explícito de caracteres em PropList.txt para oferecer suporte à retrocompatibilidade
O conjunto xid_start fecha então este conjunto sob a normalização NFKC, removendo todos os caracteres cuja normalização não é da forma id_start id_continue*.
O conjunto id_continue é definido como a união de:
id_start(veja acima)Categoria Unicode
<Nd>- números decimais (inclui0a9)Categoria Unicode
<Pc>- pontuações de conectoresCategoria Unicode
<Mn>- marcas sem espaçamentoCategoria Unicode
<Mc>- espaçamento combinando marcas<Other_ID_Continue>- outro conjunto explícito de caracteres em PropList.txt para oferecer suporte à retrocompatibilidade
Novamente, xid_continue fecha este conjunto sob a normalização NFKC.
As categorias Unicode usam a versão do Unicode Character Database (em português, banco de dados de caracteres Unicode) incluída no módulo unicodedata.
2.4. Literais¶
Literais são notações para valores constantes de alguns tipos embutidos.
Em termos de análise lexical, Python tem literais de string, de bytes e numéricos.
Outros “literais” são denotados lexicamente usando palavra reservada (None, True, False) e o token de reticências especial (...).
2.5. Literais de string e bytes¶
Literais de string são textos entre aspas simples (') ou aspas duplas ("). Por exemplo:
"spam"
'eggs'
A aspa usada para iniciar o literal também o encerra, portanto, um literal de string só pode conter a outra aspa (exceto com sequências de escape, veja abaixo). Por exemplo:
'Diga "Olá", por favor.'
"Não faça isso!"
Exceto por essa limitação, a escolha do caractere de aspas (' ou ") não afeta como o literal é analisado.
Dentro de uma literal de string, o caractere de contrabarra (\) introduz uma sequência de escape , que tem um significado especial dependendo do caractere após a contrabarra. Por exemplo, `"`` denota o caractere de aspas duplas e não encerra a string:
>>> print("Diga \"Olá\" para todo mundo!")
Diga "Olá" para todo mundo!
Veja sequências de escape abaixo para uma lista completa dessas sequências e mais detalhes.
2.5.1. Strings entre aspas triplas¶
Strings também podem ser colocadas emgrupos correspondentes de três aspas simples ou duplas. Geralmente, elas são chamadas de strings entre aspas triplas:
"""Isso é uma string entre aspas triplas."""
Em literais com aspas triplas, aspas sem escape são permitidas (e são mantidas), exceto que três aspas sem escape seguidas encerram o literal, se forem do mesmo tipo (' ou ") usadas no início:
"""Essa string tem "aspas" dentro."""
Novas linhas sem escape também são permitidas e mantidas:
'''Essa string entre aspas triplas
continua na linha seguinte.'''
2.5.2. Prefixos de string¶
Literais de string podem ter um prefixo opcional que influencia como o conteúdo do literal é analisado, por exemplo:
b"data"
f'{result=}'
Os prefixos permitidos são:
r: String brutaf: Literal de string formatada (“f-string”)t: Literal de string template (“t-string”)u: Sem efeito (permitido para retrocompatibilidade)
Veja as seções vinculadas para obter detalhes sobre cada tipo.
Prefixos não diferenciam maiúsculas de minúsculas (por exemplo, ‘B’ funciona da mesma forma que ‘b’). O prefixo ‘r’ pode ser combinado com ‘f’, ‘t’ ou ‘b’, portanto, ‘fr’, ‘rf’, ‘tr’, ‘rt’, ‘br’ e ‘rb’ também são prefixos válidos.
Adicionado na versão 3.3: O prefixo 'rb' de literais de bytes brutos foi adicionado como sinônimo de 'br'.
O suporte para o literal legado unicode (u'value') foi reintroduzido para simplificar a manutenção de bases de código duplas Python 2.x e 3.x. Consulte PEP 414 para obter mais informações.
2.5.3. Gramática formal¶
Literais de string, exceto “f-strings” e “t-strings”, são descritos pelas seguintes definições lexicais.
Essas definições usam negative lookaheads (!) para indicar que uma aspa final encerra o literal.
STRING: [stringprefix] (stringcontent) stringprefix: <("r" | "u" | "b" | "br" | "rb"), case-insensitive> stringcontent: | "'''" ( !"'''"longstringitem)* "'''" | '"""' ( !'"""'longstringitem)* '"""' | "'" ( !"'"stringitem)* "'" | '"' ( !'"'stringitem)* '"' stringitem:stringchar|stringescapeseqstringchar: <anysource_character, except backslash and newline> longstringitem:stringitem| newline stringescapeseq: "\" <anysource_character>
Observe que, como em todas as definições lexicais, os espaços em branco são significativos. Em particular, o prefixo (se houver) deve ser imediatamente seguido pela aspa inicial.
2.5.4. Sequências de escape¶
A menos que um prefixo ‘r’ ou ‘R’ esteja presente, as sequências de escape em literais de string e bytes são interpretadas de acordo com regras semelhantes àquelas usadas pelo Standard C. As sequências de escape reconhecidas são:
Sequência de escape |
Significado |
|---|---|
|
|
|
|
|
|
|
|
|
ASCII Bell (BEL) - um sinal audível é emitido |
|
ASCII Backspace (BS) - apaga caractere à esquerda |
|
ASCII Formfeed (FF) - quebra de página |
|
ASCII Linefeed (LF) - quebra de linha |
|
ASCII Carriage Return (CR) - retorno de carro |
|
ASCII Horizontal Tab (TAB) - tabulação horizontal |
|
ASCII Vertical Tab (VT) - tabulação vertical |
|
|
|
|
|
|
|
|
|
2.5.4.1. Fim de linha ignorado¶
Uma contrabarra pode ser adicionada ao fim da linha para ignorar a nova linha:
>>> 'Esta string não vai incluir \
... contrabarras e caracteres de nova linha.'
'Esta string não vai incluir contrabarras e caracteres de nova linha.'
O mesmo resultado pode ser obtido usando strings com aspas triplas, ou parênteses e concatenação de literal string.
2.5.4.2. Caracteres escapados¶
Para incluir uma contrabarra em um literal de string não-bruta Python, ela deve ser duplicada. A sequência de escape \\ denota um único caractere de contrabarra:
>>> print('C:\\Program Files')
C:\Program Files
Da mesma forma, as sequências \' e \" denotam os caracteres de aspas simples e duplas, respectivamente:
>>> print('\' e \"')
' e "
2.5.4.3. Caractere octal¶
A sequência \ooo denota um caractere com o valor octal (base 8) ooo:
>>> '\120'
'P'
São aceitos até três dígitos octais (0 a 7).
Em um literal de bytes, caractere significa um byte com o valor fornecido. Em um literal de string, significa um caractere Unicode com o valor fornecido.
Alterado na versão 3.11: Escapes octais com valor maior que 0o377 (255) produz uma DeprecationWarning.
Alterado na versão 3.12: Escapes octais com valor maior que 0o377 (255) produzem um SyntaxWarning. Em uma versão futura do Python eles eventualmente vão levantar um SyntaxError.
2.5.4.4. Caractere hexadecimal¶
A sequência \xhh denota um caractere com o valor hexa (base 16) hh:
>>> '\x50'
'P'
Ao contrário do padrão C, são necessários exatamente dois dígitos hexadecimais.
Em um literal de bytes, caractere significa um byte com o valor fornecido. Em um literal de string, significa um caractere Unicode com o valor fornecido.
2.5.4.5. Caractere nomeado Unicode¶
A sequência \N{nome} denota um caractere Unicode com o nome fornecido:
>>> '\N{LATIN CAPITAL LETTER P}'
'P'
>>> '\N{SNAKE}'
'🐍'
Esta sequência não pode aparecer em literais de bytes.
Alterado na versão 3.3: Support for name aliases has been added.
2.5.4.6. Caracteres hexadecimais Unicode¶
As sequências \uxxxx e \Uxxxxxxxx denotam o caractere Unicode com o valor hexadecimal fornecido (base 16). São necessários exatamente quatro dígitos para \u; são necessários exatamente oito dígitos para \U. Este último pode codificar qualquer caractere Unicode.
>>> '\u1234'
'ሴ'
>>> '\U0001f40d'
'🐍'
Estas sequências não pode aparecer em literais de bytes.
2.5.4.7. Sequências de espace não reconhecidas¶
Diferentemente do Standard C, todas as sequências de escape não reconhecidas são deixadas na string inalteradas, ou seja, a contrabarra é deixada no resultado:
>>> print('\q')
\q
>>> list('\q')
['\\', 'q']
Observe que, para literais de bytes, as sequências de escape reconhecidas apenas em literais de string (\N..., \u..., \U...) se enquadram na categoria de escapes não reconhecidos.
Alterado na versão 3.6: Sequências de escape não reconhecidas produzem um DeprecationWarning.
Alterado na versão 3.12: Sequências de escape não reconhecidas produzem um SyntaxWarning. Em uma versão futura do Python eles vão levantar um SyntaxError.
2.5.5. Literais de bytes¶
Literais de bytes são sempre prefixados com ‘b’ ou ‘B’; eles produzem uma instância do tipo bytes em vez do tipo str. Eles podem conter apenas caracteres ASCII; bytes com valor numérico igual ou superior a 128 devem ser expressos com sequências de escape (normalmente Caractere hexadecimal ou Caractere octal):
>>> 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]
Da mesma forma, um byte zero deve ser expresso usando uma sequência de escape (normalmente \0 ou \x00).
2.5.6. Literais de string brutas¶
Literais de string e bytes podem opcionalmente ser prefixados com uma letra ‘r’ ou ‘R’; tais construções são chamadas de literais de strings brutas e literais de bytes brutos tratam as contrabarras como caracteres literais. Como resultado, em literais de string bruta, as sequências de escape não são tratados de maneira especial.
>>> r'\d{4}-\d{2}-\d{2}'
'\\d{4}-\\d{2}-\\d{2}'
Mesmo em um literal bruto, as aspas podem ser escapadas com uma contrabarra, mas a barra invertida permanece no resultado; por exemplo, r"\"" é uma literal de string válida que consiste em dois caracteres: uma contrabarra e aspas duplas; r"\" não é uma literal de string válida (mesmo uma string bruta não pode terminar em um número ímpar de contrabarras). Especificamente, um literal bruto não pode terminar em uma única contrabarra (já que a contrabarra escaparia do seguinte caractere de aspas). Observe também que uma única contrabarra seguida por uma nova linha é interpretada como esses dois caracteres como parte do literal, não como uma continuação de linha.
2.5.7. Literais de strings formatadas¶
Adicionado na versão 3.6.
Alterado na versão 3.8: Adicionado o especificador de depuração (=)
Alterado na versão 3.12: Muitas restrições a expressões dentro de f-strings foram removidas. Notavelmente, strings aninhadas, comentários e contrabarras agora são permitidos.
Um literal de string formatada ou uma f-string é uma string literal que começa com ‘f’ ou ‘F’. Ao contrário de outras strings literais, as f-strings não têm um valor constante. Elas podem conter campos de substituição delimitados por chaves {}. Os campos de substituição contêm expressões que são avaliadas em tempo de execução. Por exemplo:
>>> who = 'Ninguém'
>>> nationality = 'Espanhola'
>>> f'{who.title()} está à espera da Inquisição {nationality}!'
'Ninguém está à espera da Inquisição Espanhola!'
Quaisquer chaves duplas ({{ ou }}) fora dos campos de substituição são substituídas pela chave simples correspondente:
>>> print(f'{{...}}')
{...}
Outros caracteres fora dos campos de substituição são tratados como em literais de string comuns. Isso significa que sequências de escape são decodificadas (exceto quando um literal também é marcado como uma string bruta) e quebras de linha são possíveis em f-strings entre aspas triplas.
>>> name = 'Galahad'
>>> favorite_color = 'blue'
>>> print(f'{name}:\t{favorite_color}')
Galahad: blue
>>> print(rf"C:\Users\{name}")
C:\Users\Galahad
>>> print(f'''Three shall be the number of the counting
... and the number of the counting shall be three.''')
Three shall be the number of the counting
and the number of the counting shall be three.
Expressions in formatted string literals are treated like regular
Python expressions.
Each expression is evaluated in the context where the formatted string literal
appears, in order from left to right.
An empty expression is not allowed, and both lambda and
assignment expressions := must be surrounded by explicit parentheses:
>>> f'{(half := 1/2)}, {half * 42}'
'0.5, 21.0'
É permitido reutilizar o tipo de aspas externas da f-string dentro de um campo de substituição:
>>> a = dict(x=2)
>>> f"abc {a["x"]} def"
'abc 2 def'
Contrabarras também são permitidas em campos de substituição e são avaliadas da mesma forma que em qualquer outro contexto:
>>> a = ["a", "b", "c"]
>>> print(f"A lista a contém:\n{"\n".join(a)}")
A lista a contém:
a
b
c
It is possible to nest f-strings:
>>> name = 'world'
>>> f'Repeated:{f' hello {name}' * 3}'
'Repeated: hello world hello world hello world'
Portable Python programs should not use more than 5 levels of nesting.
Detalhes da implementação do CPython: CPython does not limit nesting of f-strings.
Replacement expressions can contain newlines in both single-quoted and
triple-quoted f-strings and they can contain comments.
Everything that comes after a # inside a replacement field
is a comment (even closing braces and quotes).
This means that replacement fields with comments must be closed in a
different line:
>>> a = 2
>>> f"abc{a # This comment }" continues until the end of the line
... + 3}"
'abc5'
After the expression, replacement fields may optionally contain:
a debug specifier – an equal sign (
=), optionally surrounded by whitespace on one or both sides;um especificador de conversão –
!s,!rou!a; e/ouum especificador de formatação prefixado com um caractere de dois pontos (
:).
See the Standard Library section on f-strings for details on how these fields are evaluated.
As that section explains, format specifiers are passed as the second argument
to the format() function to format a replacement field value.
For example, they can be used to specify a field width and padding characters
using the Format Specification Mini-Language:
>>> number = 14.3
>>> f'{number:20.7f}'
' 14.3000000'
Top-level format specifiers may include nested replacement fields:
>>> field_size = 20
>>> precision = 7
>>> f'{number:{field_size}.{precision}f}'
' 14.3000000'
These nested fields may include their own conversion fields and format specifiers:
>>> number = 3
>>> f'{number:{field_size}}'
' 3'
>>> f'{number:{field_size:05}}'
'00000000000000000003'
However, these nested fields may not include more deeply nested replacement fields.
Formatted string literals cannot be used as docstrings, even if they do not include expressions:
>>> def foo():
... f"Not a docstring"
...
>>> print(foo.__doc__)
None
Ver também
PEP 498 – Literal String Interpolation
PEP 701 – Syntactic formalization of f-strings
str.format(), which uses a related format string mechanism.
2.5.8. Literais de string template (t-strings)¶
Adicionado na versão 3.14.
A template string literal or t-string is a string literal
that is prefixed with ‘t’ or ‘T’.
These strings follow the same syntax rules as
formatted string literals.
For differences in evaluation rules, see the
Standard Library section on t-strings
2.5.9. Formal grammar for f-strings¶
F-strings are handled partly by the lexical analyzer, which produces the
tokens FSTRING_START, FSTRING_MIDDLE
and FSTRING_END, and partly by the parser, which handles
expressions in the replacement field.
The exact way the work is split is a CPython implementation detail.
Correspondingly, the f-string grammar is a mix of lexical and syntactic definitions.
Whitespace is significant in these situations:
There may be no whitespace in
FSTRING_START(between the prefix and quote).Whitespace in
FSTRING_MIDDLEis part of the literal string contents.In
fstring_replacement_field, iff_debug_specifieris present, all whitespace after the opening brace until thef_debug_specifier, as well as whitespace immediatelly followingf_debug_specifier, is retained as part of the expression.Detalhes da implementação do CPython: The expression is not handled in the tokenization phase; it is retrieved from the source code using locations of the
{token and the token after=.
The FSTRING_MIDDLE definition uses
negative lookaheads (!)
to indicate special characters (backslash, newline, {, }) and
sequences (f_quote).
fstring:FSTRING_STARTfstring_middle*FSTRING_ENDFSTRING_START:fstringprefix("'" | '"' | "'''" | '"""') FSTRING_END:f_quotefstringprefix: <("f" | "fr" | "rf"), case-insensitive> f_debug_specifier: '=' f_quote: <the quote character(s) used in FSTRING_START> fstring_middle: |fstring_replacement_field|FSTRING_MIDDLEFSTRING_MIDDLE: | (!"\" !newline!'{' !'}' !f_quote)source_character|stringescapeseq| "{{" | "}}" | <newline, in triple-quoted f-strings only> fstring_replacement_field: | '{'f_expression[f_debug_specifier] [fstring_conversion] [fstring_full_format_spec] '}' fstring_conversion: | "!" ("s" | "r" | "a") fstring_full_format_spec: | ':'fstring_format_spec* fstring_format_spec: |FSTRING_MIDDLE|fstring_replacement_fieldf_expression: | ','.(conditional_expression| "*"or_expr)+ [","] |yield_expression
Nota
In the above grammar snippet, the f_quote and FSTRING_MIDDLE rules
are context-sensitive – they depend on the contents of FSTRING_START
of the nearest enclosing fstring.
Constructing a more traditional formal grammar from this template is left as an exercise for the reader.
The grammar for t-strings is identical to the one for f-strings, with t instead of f at the beginning of rule and token names and in the prefix.
tstring: TSTRING_START tstring_middle* TSTRING_END <rest of the t-string grammar is omitted; see above>
2.6. Literais numéricos¶
Tokens NUMBER representam literais numéricos, dos quais existem três tipos: inteiros, números de ponto flutuante e números imaginários.
NUMBER:integer|floatnumber|imagnumber
O valor numérico de um literal numérico é o mesmo que seria se fosse passado como uma string para os construtores de classe int, float ou complex, respectivamente. Observe que nem todas as entradas válidas para esses construtores também são literais válidos.
Literais numéricos não incluem um sinal; uma frase como -1 é, na verdade, uma expressão composta pelo operador unário ‘-’ e o literal 1.
2.6.1. Inteiros literais¶
Literais inteiros denotam números inteiros. Por exemplo:
7
3
2147483647
Não há limite para o comprimento de literais inteiros, exceto o que pode ser armazenado na memória disponível:
7922816251426433759354395033679228162514264337593543950336
Sublinhados podem ser usados para agrupar dígitos para melhor legibilidade e são ignorados para determinar o valor numérico do literal. Por exemplo, os seguintes literais são equivalentes:
100_000_000_000
100000000000
1_00_00_00_00_000
Sublinhados só podem ocorrer entre dígitos. Por exemplo, _123, 321_ e 123__321 não são literais válidos.
Os números inteiros podem ser especificados em binário (base 2), octal (base 8) ou hexadecimal (base 16) usando os prefixos 0b, 0o e 0x, respectivamente. Os dígitos hexadecimais de 10 a 15 são representados pelas letras A-F, sem distinção entre maiúsculas e minúsculas. Por exemplo:
0b100110111
0b_1110_0101
0o177
0o377
0xdeadbeef
0xDead_Beef
Um sublinhado pode seguir o especificador base. Por exemplo, 0x_1f é um literal válido, mas 0_x1f e 0x__1f não são.
Zeros à esquerda em um número decimal diferente de zero não são permitidos. Por exemplo, 0123 não é um literal válido. Isso serve para desambiguação com literais octais no estilo C, que o Python usava antes da versão 3.0.
Formalmente, literais inteiros são descritos pelas seguintes definições lexicais:
integer:decinteger|bininteger|octinteger|hexinteger|zerointegerdecinteger: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"
Alterado na versão 3.6: Os sublinhados agora são permitidos para fins de agrupamento de literais.
2.6.2. Literais de ponto flutuante¶
Literais de ponto flutuante (float), como 3.14 ou 1.5, denotam aproximações de números reais.
Eles consistem em partes inteiras e fracionárias, cada uma composta por dígitos decimais. As partes são separadas por um ponto decimal, .:
2.71828
4.0
Ao contrário dos literais inteiros, zeros à esquerda são permitidos nas partes numéricas. Por exemplo, 077.010 é válido e denota o mesmo número que 77.01.
Assim como em literais inteiros, sublinhados simples podem ocorrer entre dígitos para ajudar na legibilidade:
96_485.332_123
3.14_15_93
Qualquer uma dessas partes, mas não ambas, pode estar vazia. Por exemplo:
10. # (equivalente a 10.0)
.001 # (equivalente a 0.001)
Opcionalmente, o inteiro e a fração podem ser seguidos por um expoente: a letra e ou E, seguida por um sinal opcional, + ou -, e um número no mesmo formato das partes inteira e fracionária. O e ou E representa “dez vezes elevado à potência de”:
1.0e3 # (representa 1.0×10³ ou 1000.0)
1.166e-5 # (representa 1.166×10⁻⁵ ou 0.00001166)
6.02214076e+23 # (representa 6.02214076×10²³ ou 602214076000000000000000.)
Em floats com apenas partes inteiras e expoentes, o ponto decimal pode ser omitido:
1e3 # (equivalente a 1.e3 e 1.0e3)
0e0 # (equivalente a 0.)
Formalmente, literais de ponto flutuante são descritos pelas seguintes definições léxicas:
floatnumber: |digitpart"." [digitpart] [exponent] | "."digitpart[exponent] |digitpartexponentdigitpart:digit(["_"]digit)* exponent: ("e" | "E") ["+" | "-"]digitpart
Alterado na versão 3.6: Os sublinhados agora são permitidos para fins de agrupamento de literais.
2.6.3. Literais imaginários¶
Python possui objetos número complexo, mas não possui literais complexos. Em vez disso, literais imaginários denotam números complexos com parte real zero.
Por exemplo, na matemática, o número complexo 3+4.2i é escrito como o número real 3 somado ao número imaginário 4.2i. Python usa uma sintaxe semelhante, exceto que a unidade imaginária é escrita como j em vez de i:
3+4.2j
Esta é uma expressão composta pelo literal inteiro 3, o operador ‘+’ e o literal imaginário 4.2j. Como esses são três tokens separados, espaços em branco são permitidos entre eles:
3 + 4.2j
Nenhum espaço em branco é permitido dentro de cada token. Em particular, o sufixo j não pode ser separado do número que o precede.
O número antes do j tem a mesma sintaxe de um literal de ponto flutuante. Portanto, os seguintes são literais imaginários válidos:
4.2j
3.14j
10.j
.001j
1e100j
3.14e-10j
3.14_15_93j
Ao contrário de um literal de ponto flutuante, o ponto decimal pode ser omitido se o número imaginário tiver apenas uma parte inteira. O número ainda é avaliado como um número de ponto flutuante, não um inteiro.
10j
0j
1000000000000000000000000j # equivalente a 1e+24j
O sufixo j não diferencia maiúsculas de minúsculas. Isso significa que você pode usar J em vez disso:
3.14J # equivalente a 3.14j
Formalmente, literais imaginários são descritos pela seguinte definição léxica:
imagnumber: (floatnumber|digitpart) ("j" | "J")
2.7. Operadores e delimitadores¶
A seguinte gramática define os tokens de operador e de delimitador, ou seja, o tipo de token genérico OP. Uma lista destes tokens e seus nomes também está disponível na documentação do módulo token.
OP: | assignment_operator | bitwise_operator | comparison_operator | enclosing_delimiter | other_delimiter | arithmetic_operator | "..." | other_op assignment_operator: "+=" | "-=" | "*=" | "**=" | "/=" | "//=" | "%=" | "&=" | "|=" | "^=" | "<<=" | ">>=" | "@=" | ":=" bitwise_operator: "&" | "|" | "^" | "~" | "<<" | ">>" comparison_operator: "<=" | ">=" | "<" | ">" | "==" | "!=" enclosing_delimiter: "(" | ")" | "[" | "]" | "{" | "}" other_delimiter: "," | ":" | "!" | ";" | "=" | "->" arithmetic_operator: "+" | "-" | "**" | "*" | "//" | "/" | "%" other_op: "." | "@"
Nota
Geralmente, operadores são usados para combinar expressões, enquanto que os delimitadores servem para outras coisas. Entretanto, não há distinção formal clara entre essas duas categorias.
Alguns tokens podem servir tanto como operadores quanto delimitadores, dependendo da forma de uso. Por exemplo, * é tanto o operador de multiplicação quanto o delimitador usado para desempacotamento de sequências, e @ é ao mesmo tempo a multiplicação de matrizes e o delimitador que introduz decoradores.
Para alguns tokens, a distinção não é clara. Por exemplo, alguns consideram ., ( e ) como sendo delimitadores, enquanto outros enxergam aí o operador getattr() e o(s) operador(es) de chamada de função.
Alguns operadores do Python, como and, or e not in, usam tokens de palavra reservada ao invés de “símbolos” (tokens de operador).
Uma sequência de três pontos consecutivos (...) tem o significado especial de ser um literal de Ellipsis.
2.1.3. Comentários¶
Um comentário inicia com um caracter cerquilha (
#) que não é parte de uma string literal, e termina com o fim da linha física. Um comentário significa o fim da linha lógica a menos que regras de junção de linha implicitas sejam invocadas. Comentários são ignorados pela sintaxe.