2. Análisis léxico
******************

Un programa de Python es leído por un *parser* (analizador
sintáctico).  Los datos introducidos en el analizador son un flujo de
*tokens*, generados por el *analizador léxico*.  Este capítulo
describe cómo el analizador léxico desglosa un archivo en tokens.

Python lee el texto del programa como puntos de código Unicode; la
codificación de un archivo fuente puede ser dada por una declaración
de codificación y por defecto es UTF-8, ver **PEP 3120** para más
detalles.  Si el archivo fuente no puede ser decodificado, se genera
un "SyntaxError".


2.1. Estructura de línea
========================

Un programa Python se divide en un número de *líneas lógicas*.


2.1.1. Líneas lógicas
---------------------

El final de una línea lógica está representado por el token NEWLINE
(nueva línea).  Las declaraciones no pueden cruzar los límites de la
línea lógica, excepto cuando la sintaxis permite la utilización de
NEWLINE (por ejemplo, entre declaraciones en declaraciones
compuestas). Una línea lógica se construye a partir de una o más
*líneas físicas* siguiendo las reglas explícitas o implícitas de
*unión de líneas*.


2.1.2. Líneas físicas
---------------------

Una línea física es una secuencia de caracteres terminada por una
secuencia de final de línea.  En los archivos fuente y las cadenas, se
puede utilizar cualquiera de las secuencias de terminación de línea de
la plataforma estándar: el formulario Unix que utiliza ASCII LF (salto
de línea, por el inglés *linefeed*), el formulario Windows que utiliza
la secuencia ASCII CR LF (retorno seguido de salto de línea), o el
antiguo formulario Macintosh que utiliza el carácter ASCII CR
(retorno).  Todas estas formas pueden ser utilizadas por igual,
independientemente de la plataforma. El final de la introducción de
datos también sirve como un terminador implícito para la línea física
final.

Al incrustar Python, las cadenas de código fuente deben ser pasadas a
las APIs de Python usando las convenciones estándar de C para los
caracteres de nueva línea (el carácter "\n", que representa ASCII LF,
es el terminador de línea).


2.1.3. Comentarios
------------------

Un comentario comienza con un carácter de almohadilla ("#") que no es
parte de un literal de cadena, y termina al final de la línea física.
Un comentario implica el final de la línea lógica, a menos que se
invoque la regla implícita de unión de líneas. Los comentarios son
ignorados por la sintaxis.


2.1.4. Declaración de Codificación
----------------------------------

Si un comentario en la primera o segunda línea del script de Python
coincide con la expresión regular "coding[=:]\s*([-\w.]+)", este
comentario se procesa como una declaración de codificación; el primer
grupo de esta expresión denomina la codificación del archivo de código
fuente. La declaración de codificación debe aparecer en una línea
propia. Si se trata de la segunda línea, la primera línea debe ser
también una línea solamente de comentario. Las formas recomendadas de
una expresión de codificación son

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

que también es reconocido por GNU Emacs y

   # vim:fileencoding=<encoding-name>

que es reconocido por el VIM de Bram Moolenaar.

Si no se encuentra una declaración de codificación, la codificación
por defecto es UTF-8.  Además, si los primeros bytes del archivo son
la marca de orden de bytes UTF-8 ("b'\xef\xbb\xbf'"), la codificación
declarada del archivo es UTF-8 (esto está soportado, entre otros, por
el programa **notepad** de Microsoft).

If an encoding is declared, the encoding name must be recognized by
Python (see Codificaciones estándar). The encoding is used for all
lexical analysis, including string literals, comments and identifiers.


2.1.5. Unión explícita de líneas
--------------------------------

Dos o más líneas físicas pueden unirse en líneas lógicas utilizando
caracteres de barra invertida ("\"), de la siguiente manera: cuando
una línea física termina en una barra invertida que no es parte de
literal de cadena o de un comentario, se une con la siguiente formando
una sola línea lógica, borrando la barra invertida y el siguiente
carácter de fin de línea.  Por ejemplo:

   if 1900 < year < 2100 and 1 <= month <= 12 \
      and 1 <= day <= 31 and 0 <= hour < 24 \
      and 0 <= minute < 60 and 0 <= second < 60:   # Looks like a valid date
           return 1

Una línea que termina en una barra invertida no puede llevar un
comentario.  Una barra invertida no continúa un comentario.  Una barra
invertida no continúa un token excepto para los literales de la cadena
(es decir, los tokens que no sean literales de la cadena no pueden ser
divididos a través de líneas físicas usando una barra invertida).  La
barra invertida es ilegal en cualquier parte de una línea fuera del
literal de la cadena.


2.1.6. Unión implícita de líneas
--------------------------------

Las expresiones entre paréntesis, entre corchetes o entre rizos pueden
dividirse en más de una línea física sin usar barras invertidas. Por
ejemplo:

   month_names = ['Januari', 'Februari', 'Maart',      # These are the
                  'April',   'Mei',      'Juni',       # Dutch names
                  'Juli',    'Augustus', 'September',  # for the months
                  'Oktober', 'November', 'December']   # of the year

Las líneas continuas implícitas pueden llevar comentarios.  La sangría
de las líneas de continuación no es importante.  Se permiten líneas de
continuación en blanco. No hay ningún token NEWLINE (nueva línea)
entre las líneas de continuación implícitas.  Las líneas de
continuación implícitas también pueden aparecer dentro de cadenas de
triple comilla ( ver más adelante); en ese caso no pueden llevar
comentarios.


2.1.7. Líneas en blanco
-----------------------

Una línea lógica que contiene sólo espacios, tabulaciones, saltos de
página y posiblemente un comentario, es ignorada (es decir, no se
genera un símbolo de NEWLINE).  Durante la introducción interactiva de
declaraciones, el manejo de una línea en blanco puede variar
dependiendo de la implementación del bucle de *read-eval-print*
(lectura-evaluación-impresión).  En el intérprete interactivo
estándar, una línea lógica completamente en blanco (es decir, una que
no contiene ni siquiera un espacio en blanco o un comentario) termina
una declaración de varias líneas.


2.1.8. Sangría
--------------

El espacio en blanco ( espacios y tabulaciones) al principio de una
línea lógica se utiliza para calcular el nivel de sangría de la línea,
que a su vez se utiliza para determinar la agrupación de las
declaraciones.

Los tabuladores se sustituyen (de izquierda a derecha) por uno a ocho
espacios, de manera que el número total de caracteres hasta el
reemplazo inclusive es un múltiplo de ocho (se pretende que sea la
misma regla que la utilizada por Unix).  El número total de espacios
que preceden al primer carácter no en blanco determina entonces la
sangría de la línea.  La sangría no puede dividirse en múltiples
líneas físicas utilizando barras invertidas; el espacio en blanco
hasta la primera barra invertida determina la sangría.

La indentación se rechaza como inconsistente si un archivo fuente
mezcla tabulaciones y espacios de manera que el significado depende
del valor de una tabulación en los espacios; un "TabError" se produce
en ese caso.

**Nota de compatibilidad entre plataformas:** debido a la naturaleza
de los editores de texto en plataformas que no sean UNIX, no es
aconsejable utilizar una mezcla de espacios y tabuladores para la
sangría en un solo archivo de origen.  También debe tenerse en cuenta
que las diferentes plataformas pueden limitar explícitamente el nivel
máximo de sangría.

Un carácter *formfeed* puede estar presente al comienzo de la línea;
será ignorado para los cálculos de sangría anteriores.  Los caracteres
*formfeed* que aparecen en otras partes del espacio en blanco inicial
tienen un efecto indefinido (por ejemplo, pueden poner a cero el
recuento de espacio).

Los niveles de sangría de las líneas consecutivas se utilizan para
generar tokens INDENT y DEDENT, utilizando una pila, de la siguiente
manera.

Antes de que se lea la primera línea del archivo, se empuja un solo
cero en la pila; esto no volverá a saltar.  Los números empujados en
la pila siempre irán aumentando estrictamente de abajo hacia arriba.
Al principio de cada línea lógica, el nivel de sangría de la línea se
compara con la parte superior de la pila. Si es igual, no pasa nada.
Si es mayor, se empuja en la pila, y se genera un token INDENT.  Si es
más pequeño, *debe* ser uno de los números de la pila; todos los
números de la pila que son más grandes se sacan, y por cada número
sacado se genera un token DEDENT.  Al final del archivo, se genera un
token DEDENT por cada número restante de la pila que sea mayor que
cero.

Aquí hay un ejemplo de un código de Python con una correcta (aunque no
tan clara) sangría:

   def perm(l):
           # Compute the list of all permutations of 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

El siguiente ejemplo muestra varios errores de sangría:

    def perm(l):                       # error: first line indented
   for i in range(len(l)):             # error: not indented
       s = l[:i] + l[i+1:]
           p = perm(l[:i] + l[i+1:])   # error: unexpected indent
           for x in p:
                   r.append(l[i:i+1] + x)
               return r                # error: inconsistent dedent

(En realidad, los tres primeros errores son detectados por el
analizador; sólo el último error es encontrado por el analizador
léxico --- la sangría de "return r" no coincide con un nivel sacado de
la pila.)


2.1.9. Espacios en blanco entre tokens
--------------------------------------

A excepción del comienzo de una línea lógica o en los literales de
cadenas, los caracteres de espacio en blanco, tabulación y formfeed
pueden utilizarse indistintamente para separar tokens.  Los espacios
en blanco se necesitan entre dos tokens sólo si su concatenación
podría interpretarse de otra manera como un token diferente (por
ejemplo, ab es un token, pero a b corresponde a dos tokens).


2.2. Otros tokens
=================

Además de NEWLINE, INDENT y DEDENT, existen las siguientes categorías
de fichas: *identifiers* (identificadores), *keywords* (palabras
clave), *literals* (literales), *operators* (operadores) y
*delimiters* (delimitadores). Los caracteres de espacio en blanco
(distintos de los terminadores de línea, discutidos anteriormente) no
son tokens, pero sirven para delimitarlos. En los casos en que exista
ambigüedad, un token comprende la cadena más larga posible que forma
un token legal cuando se lee de izquierda a derecha.


2.3. Identificadores y palabras clave
=====================================

Los identificadores (también denominados *nombres*) se describen
mediante las siguientes definiciones léxicas.

La sintaxis de los identificadores en Python se basa en el anexo
estándar de Unicode UAX-31, con la elaboración y los cambios que se
definen a continuación; ver también **PEP 3131** para más detalles.

Dentro del rango ASCII (U+0001..U+007F), los caracteres válidos para
los identificadores son los mismos que en Python 2.x: las letras
mayúsculas y minúsculas "A" hasta "Z", el guión bajo "_" y los dígitos
"0" hasta "9", salvo el primer carácter.

Python 3.0 introduce caracteres adicionales fuera del rango ASCII (ver
**PEP 3131**).  Para estos caracteres, la clasificación utiliza la
versión de la base de datos de caracteres Unicode incluida en el
módulo "unicodedata".

Los identificadores son de extensión ilimitada.  Las mayúsculas y
minúsculas son significativas.

   identifier   ::= xid_start xid_continue*
   id_start     ::= <all characters in general categories Lu, Ll, Lt, Lm, Lo, Nl, the underscore, and characters with the Other_ID_Start property>
   id_continue  ::= <all characters in id_start, plus characters in the categories Mn, Mc, Nd, Pc and others with the Other_ID_Continue property>
   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*">

Los códigos de la categoría Unicode mencionados anteriormente
representan:

* *Lu* - letras mayúsculas

* *Ll* - letras minúsculas

* *Lt* - letras de *titlecase*

* *Lm* - letras modificadoras

* *Lo* - otras letras

* *Nl* - números de letra

* *Mn* - marcas sin separación

* *Mc* - marcas de combinación de separación

* *Nd* - números decimales

* *Pc* - puntuaciones conectoras

* *Other_ID_Start* - lista explícita de caracteres en PropList.txt
  para apoyar la compatibilidad hacia atrás

* *Other_ID_Continue* - Así mismo

Todos los identificadores se convierten en la forma normal NFKC
mientras se analizan; la comparación de los identificadores se basa en
NFKC.

Puede encontrar un archivo HTML no normativo que enumera todos los
caracteres identificadores válidos para Unicode 4.1 en
https://www.unicode.org/Public/13.0.0/ucd/DerivedCoreProperties.txt


2.3.1. Palabras clave
---------------------

Los siguientes identificadores se utilizan como palabras reservadas, o
*palabras clave* del idioma, y no pueden utilizarse como
identificadores ordinarios.  Deben escribirse exactamente como están
escritas aquí:

   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. Palabras clave suaves
----------------------------

Nuevo en la versión 3.10.

Algunos identificadores solo están reservados en contextos
específicos. Estos se conocen como *palabras clave suaves*. Los
identificadores "match", "case" y "_" pueden actuar sintácticamente
como palabras clave en contextos relacionados con la declaración de
coincidencia de patrones, pero esta distinción se realiza en el nivel
del analizador, no cuando se tokeniza.

Como palabras clave suaves, su uso con la coincidencia de patrones es
posible sin dejar de preservar la compatibilidad con el código
existente que usa "match", "case" y "_" como nombres de
identificadores.


2.3.3. Clases reservadas de identificadores
-------------------------------------------

Ciertas clases de identificadores (además de las palabras clave)
tienen significados especiales.  Estas clases se identifican por los
patrones de los caracteres de guión bajo que van delante y detrás:

"_*"
   No importado por "from module import *".

"_"
   En un patrón "case" dentro de una declaración "match", "_" es una
   palabra clave suave que denota un comodín wildcard.

   Por separado, el intérprete interactivo pone a disposición el
   resultado de la última evaluación en la variable "_". (Se almacena
   en el módulo "builtins", junto con funciones incorporadas como
   "print").

   En otros lugares, "_" es un identificador regular. A menudo se usa
   para nombrar elementos "especiales", pero no es especial para
   Python en sí.

   Nota:

     El nombre "_" se usa a menudo en conjunción con la
     internacionalización; consultar la documentación del módulo
     "gettext`" para más información sobre esta convención.También se
     usa comúnmente para variables no utilizadas.

"__*__"
   Nombres definidos por el sistema, conocidos informalmente como
   nombres "*dunder*". Estos nombres son definidos por el intérprete y
   su aplicación (incluida la biblioteca estándar). Los nombres
   actuales del sistema se discuten en la sección Nombres especiales
   de método y en otros lugares. Es probable que se definan más en
   futuras versiones de Python.  *Cualquier* uso de nombres "__*__",
   en cualquier contexto, que no siga un uso explícitamente
   documentado, está sujeto a que se rompa sin previo aviso.

"__*"
   Nombres de clase privada.  Los nombres de esta categoría, cuando se
   utilizan en el contexto de una definición de clase, se reescriben
   para utilizar una forma desfigurada que ayude a evitar conflictos
   de nombres entre los atributos "privados" de las clases base y
   derivadas. Ver la sección Identificadores (Nombres).


2.4. Literales
==============

Los literales son notaciones para los valores constantes de algunos
tipos incorporados.


2.4.1. Literales de cadenas y bytes
-----------------------------------

Los literales de cadena se describen mediante las siguientes
definiciones léxicas:

   stringliteral   ::= [stringprefix](shortstring | longstring)
   stringprefix    ::= "r" | "u" | "R" | "U" | "f" | "F"
                    | "fr" | "Fr" | "fR" | "FR" | "rf" | "rF" | "Rf" | "RF"
   shortstring     ::= "'" shortstringitem* "'" | '"' shortstringitem* '"'
   longstring      ::= "'''" longstringitem* "'''" | '"""' longstringitem* '"""'
   shortstringitem ::= shortstringchar | stringescapeseq
   longstringitem  ::= longstringchar | stringescapeseq
   shortstringchar ::= <any source character except "\" or newline or the quote>
   longstringchar  ::= <any source character except "\">
   stringescapeseq ::= "\" <any source character>

   bytesliteral   ::= bytesprefix(shortbytes | longbytes)
   bytesprefix    ::= "b" | "B" | "br" | "Br" | "bR" | "BR" | "rb" | "rB" | "Rb" | "RB"
   shortbytes     ::= "'" shortbytesitem* "'" | '"' shortbytesitem* '"'
   longbytes      ::= "'''" longbytesitem* "'''" | '"""' longbytesitem* '"""'
   shortbytesitem ::= shortbyteschar | bytesescapeseq
   longbytesitem  ::= longbyteschar | bytesescapeseq
   shortbyteschar ::= <any ASCII character except "\" or newline or the quote>
   longbyteschar  ::= <any ASCII character except "\">
   bytesescapeseq ::= "\" <any ASCII character>

One syntactic restriction not indicated by these productions is that
whitespace is not allowed between the "stringprefix" or "bytesprefix"
and the rest of the literal. The source character set is defined by
the encoding declaration; it is UTF-8 if no encoding declaration is
given in the source file; see section Declaración de Codificación.

In plain English: Both types of literals can be enclosed in matching
single quotes ("'") or double quotes (""").  They can also be enclosed
in matching groups of three single or double quotes (these are
generally referred to as *triple-quoted strings*). The backslash ("\")
character is used to give special meaning to otherwise ordinary
characters like "n", which means 'newline' when escaped ("\n"). It can
also be used to escape characters that otherwise have a special
meaning, such as newline, backslash itself, or the quote character.
See escape sequences below for examples.

Los literales de bytes siempre se prefijan con "'b'" o "'B'"; producen
una instancia del tipo "bytes" en lugar del tipo "str".  Sólo pueden
contener caracteres ASCII; los bytes con un valor numérico de 128 o
mayor deben ser expresados con escapes.

Tanto los literales de cadena como de bytes pueden ser prefijados con
una letra "'r'" o "'R'"; tales cadenas se llaman *raw strings* y
consideran las barras inversas como caracteres literales.  Como
resultado, en las cadenas literales, los escapes de "'\U'" y "'\u'" en
las cadenas sin procesar no son tratados de manera especial. Dado que
los literales *raw* de unicode de Python 2.x se comportan de manera
diferente a los de Python 3.x, la sintaxis de "'ur'" no está
soportada.

Nuevo en la versión 3.3: El prefijo "'rb'" de literales de bytes raw
se ha añadido como sinónimo de "'br'".

Nuevo en la versión 3.3: Se reintrodujo el soporte para el legado
unicode literal ("u'value'") para simplificar el mantenimiento de las
bases de código dual Python 2.x y 3.x. Ver **PEP 414** para más
información.

Un literal de cadena con "'f'" o "'F'" en su prefijo es un *formatted
string literal*; ver Literales de cadena formateados.  La "'f'" puede
combinarse con la "'r'", pero no con la "'b'" o "'u'", por lo que las
cadenas *raw* formateadas son posibles, pero los literales de bytes
formateados no lo son.

En los literales de triple cita, se permiten (y se retienen) nuevas
líneas y citas no escapadas, excepto cuando tres citas no escapadas
seguidas finalizan el literal.  (Una "cita" es el carácter utilizado
para abrir el literal, es decir, ya sea "'" o """.)

A menos que un prefijo "'r'" o "'R'" esté presente, las secuencias de
escape en literales de cadena y bytes se interpretan según reglas
similares a las usadas por C estándar. Las secuencias de escape
reconocidas son:

+-------------------+-----------------------------------+---------+
| Secuencia de      | Significado                       | Notas   |
| escape            |                                   |         |
|===================|===================================|=========|
| "\"<newline>      | Barra inversa y línea nueva       | (1)     |
|                   | ignoradas                         |         |
+-------------------+-----------------------------------+---------+
| "\\"              | Barra inversa ("\")               |         |
+-------------------+-----------------------------------+---------+
| "\'"              | Comilla simple ("'")              |         |
+-------------------+-----------------------------------+---------+
| "\""              | Comilla doble (""")               |         |
+-------------------+-----------------------------------+---------+
| "\a"              | ASCII Bell (BEL)                  |         |
+-------------------+-----------------------------------+---------+
| "\b"              | ASCII Retroceso (BS)              |         |
+-------------------+-----------------------------------+---------+
| "\f"              | ASCII Formfeed (FF)               |         |
+-------------------+-----------------------------------+---------+
| "\n"              | ASCII Linefeed (LF)               |         |
+-------------------+-----------------------------------+---------+
| "\r"              | ASCII Retorno de carro (CR)       |         |
+-------------------+-----------------------------------+---------+
| "\t"              | ASCII Sangría horizontal (TAB)    |         |
+-------------------+-----------------------------------+---------+
| "\v"              | ASCII Sangría vertical (VT)       |         |
+-------------------+-----------------------------------+---------+
| "\ooo"            | Carácter con valor octal *ooo*    | (2,4)   |
+-------------------+-----------------------------------+---------+
| "\xhh"            | Carácter con valor hexadecimal    | (3,4)   |
|                   | *hh*                              |         |
+-------------------+-----------------------------------+---------+

Las secuencias de escape que sólo se reconocen en los literales de
cadena son:

+-------------------+-----------------------------------+---------+
| Secuencia de      | Significado                       | Notas   |
| escape            |                                   |         |
|===================|===================================|=========|
| "\N{name}"        | El carácter llamado *name* en la  | (5)     |
|                   | base de datos de Unicode          |         |
+-------------------+-----------------------------------+---------+
| "\uxxxx"          | Carácter con valor hexadecimal de | (6)     |
|                   | 16 bits *xxxx*                    |         |
+-------------------+-----------------------------------+---------+
| "\Uxxxxxxxx"      | Carácter con valor hexadecimal de | (7)     |
|                   | 32 bits *xxxxxxxx*                |         |
+-------------------+-----------------------------------+---------+

Notas:

1. A backslash can be added at the end of a line to ignore the
   newline:

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

   The same result can be achieved using triple-quoted strings, or
   parentheses and string literal concatenation.

2. Como en C estándar, se aceptan hasta tres dígitos octales.

3. A diferencia de C estándar, se requieren exactamente dos dígitos
   hexadecimales.

4. En un literal de bytes, los escapes hexadecimal y octal denotan el
   byte con el valor dado. En un literal de cadena, estos escapes
   denotan un carácter Unicode con el valor dado.

5. Distinto en la versión 3.3: Se ha añadido el soporte para los alias
   de nombres [1].

6. Se requieren exactamente cuatro dígitos hexadecimales.

7. Cualquier carácter Unicode puede ser codificado de esta manera.  Se
   requieren exactamente ocho dígitos hexadecimales.

A diferencia de C estándar, todas las secuencias de escape no
reconocidas se dejan en la cadena sin cambios, es decir, *la barra
invertida se deja en el resultado*.  (Este comportamiento es útil para
la depuración: si una secuencia de escape se escribe mal, la salida
resultante se reconoce más fácilmente como rota).  También es
importante señalar que las secuencias de escape sólo reconocidas en
los literales de cadena caen en la categoría de escapes no reconocidos
para los literales de bytes.

   Distinto en la versión 3.6: Las secuencias de escape no reconocidas
   producen un "DeprecationWarning".  En una futura versión de Python
   serán un "SyntaxWarning" y eventualmente un "SyntaxError".

Incluso en un literal *raw*, las comillas se pueden escapar con una
barra inversa, pero la barra inversa permanece en el resultado; por
ejemplo, "r"\""" es un literal de cadena válido que consiste en dos
caracteres: una barra inversa y una comilla doble; "r"\"" no es un
literal de cadena válido (incluso una cadena en bruto no puede
terminar en un número impar de barras inversas).  Específicamente, *un
literal raw no puede terminar en una sola barra inversa* (ya que la
barra inversa se escaparía del siguiente carácter de comillas). Nótese
también que una sola barra inversa seguida de una nueva línea se
interpreta como esos dos caracteres como parte del literal, *no* como
una continuación de línea.


2.4.2. Concatenación de literales de cadena
-------------------------------------------

Se permiten múltiples literales de cadenas o bytes adyacentes
(delimitados por espacios en blanco), posiblemente utilizando
diferentes convenciones de citas, y su significado es el mismo que su
concatenación.  Por lo tanto, ""hola" 'mundo'" es equivalente a
""holamundo"".  Esta característica puede ser utilizada para reducir
el número de barras inversas necesarias, para dividir largas cadenas
convenientemente a través de largas líneas, o incluso para añadir
comentarios a partes de las cadenas, por ejemplo:

   re.compile("[A-Za-z_]"       # letter or underscore
              "[A-Za-z0-9_]*"   # letter, digit or underscore
             )

Téngase en cuenta que esta característica se define a nivel
sintáctico, pero se implementa en el momento de la compilación.  El
operador '+' debe ser usado para concatenar expresiones de cadena al
momento de la ejecución.  Observar también que la concatenación de
literales puede utilizar diferentes estilos de citas para cada
componente (incluso mezclando cadenas *raw* y cadenas con triple
comilla), y los literales de cadena formateados pueden ser
concatenados con los literales de cadena simples.


2.4.3. Literales de cadena formateados
--------------------------------------

Nuevo en la versión 3.6.

Un *formatted string literal* o *f-string* es un literal de cadena que
se prefija con "'f'" o "'F'".  Estas cadenas pueden contener campos de
reemplazo, que son expresiones delimitadas por llaves "{}". Mientras
que otros literales de cadena siempre tienen un valor constante, las
cadenas formateadas son realmente expresiones evaluadas en tiempo de
ejecución.

Las secuencias de escape se decodifican como en los literales de
cadena ordinarios (excepto cuando un literal también se marca como
cadena *raw*).  Después de la decodificación, la gramática para el
contenido de la cadena es:

   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 | NULL | replacement_field)*
   literal_char      ::= <any code point except "{", "}" or NULL>

Las partes de la cadena fuera de las llaves se tratan literalmente,
excepto que las llaves dobles "'{{'" o "'}}'" se reemplazan con la
llave simple correspondiente. Un solo corchete de apertura "'{'" marca
un campo de reemplazo, que comienza con una expresión de Python. Para
mostrar tanto el texto de la expresión como su valor después de la
evaluación (útil en la depuración), se puede agregar un signo igual
"'='" después de la expresión. Puede seguir un campo de conversión,
introducido por un signo de exclamación "'!'". También se puede
agregar un especificador de formato, introducido por dos puntos "':'".
Un campo de reemplazo termina con un corchete de cierre "'}'".

Las expresiones en literales de cadena formateados se tratan como
expresiones regulares de Python rodeadas de paréntesis, con algunas
excepciones. Una expresión vacía no está permitida, y tanto "lambda"
como las expresiones de asignación ":=" deben estar rodeadas de
paréntesis explícitos. Las expresiones de sustitución pueden contener
saltos de línea (por ejemplo, en cadenas de tres comillas), pero no
pueden contener comentarios.  Cada expresión se evalúa en el contexto
en el que aparece el literal de cadena formateado, en orden de
izquierda a derecha.

Distinto en la versión 3.7: Antes de Python 3.7, una expresión "await"
y comprensiones que contenían una cláusula "async for" eran ilegales
en las expresiones en literales de cadenas formateadas debido a un
problema con la implementación.

Cuando se proporciona el signo igual "'='", la salida tendrá el texto
de expresión, el "'='" y el valor evaluado. Los espacios después de la
llave de apertura "'{'", dentro de la expresión y después de "'='" se
conservan en la salida. Por defecto, el "'='" hace que se proporcione
"repr()" de la expresión, a menos que haya un formato especificado.
Cuando se especifica un formato, el valor predeterminado es "str()" de
la expresión a menos que se declare una conversión "'!r'".

Nuevo en la versión 3.8: El símbolo igual "'='".

Si se especifica una conversión, el resultado de la evaluación de la
expresión se convierte antes del formateo.  La conversión "`!s'" llama
"str()" al resultado, "`!r'" llama "repr()", y "`!a'" llama "ascii()".

El resultado es entonces formateado usando el protocolo "format()".
El especificador de formato se pasa al método "__format__()" del
resultado de la expresión o conversión.  Se pasa una cadena vacía
cuando se omite el especificador de formato.  El resultado formateado
se incluye entonces en el valor final de toda la cadena.

Top-level format specifiers may include nested replacement fields.
These nested fields may include their own conversion fields and format
specifiers, but may not include more deeply nested replacement fields.
The format specifier mini-language is the same as that used by the
"str.format()" method.

Los literales de cadena formateados pueden ser concatenados, pero los
campos de reemplazo no pueden ser divididos entre los literales.

Algunos ejemplos de literales de cadena formateados:

   >>> 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" '

Una consecuencia de compartir la misma sintaxis que los literales de
cadena regulares es que los caracteres en los campos de reemplazo no
deben entrar en conflicto con la comilla usada en el literal de cadena
formateado exterior:

   f"abc {a["x"]} def"    # error: outer string literal ended prematurely
   f"abc {a['x']} def"    # workaround: use different quoting

Las barras inversas no están permitidas en las expresiones de formato
y generarán un error:

   f"newline: {ord('\n')}"  # raises SyntaxError

Para incluir un valor en el que se requiere un escape de barra
inversa, hay que crear una variable temporal.

>>> newline = ord('\n')
>>> f"newline: {newline}"
'newline: 10'

Los literales de cadena formateados no pueden ser usados como cadenas
de documentos (*docstrings*), aunque no incluyan expresiones.

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

Ver también **PEP 498** para la propuesta que añadió literales de
cadenas formateados, y "str.format()", que utiliza un mecanismo de
cadenas formateadas relacionado.


2.4.4. Literales numéricos
--------------------------

Hay tres tipos de literales numéricos: números enteros, números de
punto flotante y números imaginarios.  No hay literales complejos (los
números complejos pueden formarse sumando un número real y un número
imaginario).

Nótese que los literales numéricos no incluyen un signo; una frase
como "-1" es en realidad una expresión compuesta por el operador
unario '"-"' y el literal "1".


2.4.5. Literales enteros
------------------------

Los literales enteros se describen mediante las siguientes
definiciones léxicas:

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

No hay límite para la longitud de los literales enteros aparte de lo
que se puede almacenar en la memoria disponible.

Los guiones bajos se ignoran para determinar el valor numérico del
literal.  Se pueden utilizar para agrupar los dígitos para mejorar la
legibilidad.  Un guión bajo puede ocurrir entre dígitos y después de
especificadores de base como "0x".

Nótese que no se permiten los ceros a la izquierda en un número
decimal que no sea cero. Esto es para desambiguar con los literales
octales de estilo C, que Python usaba antes de la versión 3.0.

Algunos ejemplos de literales enteros:

   7     2147483647                        0o177    0b100110111
   3     79228162514264337593543950336     0o377    0xdeadbeef
         100_000_000_000                   0b_1110_0101

Distinto en la versión 3.6: Los guiones bajos están ahora permitidos
para agrupar en literales.


2.4.6. Literales de punto flotante
----------------------------------

Los literales de punto flotante se describen en las siguientes
definiciones léxicas:

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

Nótese que las partes enteras y exponentes siempre se interpretan
usando el radix 10. Por ejemplo, "077e010" es legal, y denota el mismo
número que "77e10". El rango permitido de los literales de punto
flotante depende de la implementación.  Al igual que en los literales
enteros, se admiten guiones bajos para la agrupación de dígitos.

Algunos ejemplos de literales de punto flotante:

   3.14    10.    .001    1e100    3.14e-10    0e0    3.14_15_93

Distinto en la versión 3.6: Los guiones bajos están ahora permitidos
para agrupar en literales.


2.4.7. Literales imaginarios
----------------------------

Los literales imaginarios se describen en las siguientes definiciones
léxicas:

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

Un literal imaginario da un número complejo con una parte real de 0.0.
Los números complejos se representan como un par de números de punto
flotante y tienen las mismas restricciones en su rango.  Para crear un
número complejo con una parte real distinta de cero, añada un número
de punto flotante, por ejemplo, "(3+4j)".  Algunos ejemplos de
literales imaginarios:

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


2.5. Operadores
===============

Los siguientes tokens son operadores:

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


2.6. Delimitadores
==================

Los siguientes tokens sirven como delimitadores en la gramática:

   (       )       [       ]       {       }
   ,       :       .       ;       @       =       ->
   +=      -=      *=      /=      //=     %=      @=
   &=      |=      ^=      >>=     <<=     **=

El punto también puede ocurrir en los literales de punto flotante e
imaginarios.  Una secuencia de tres períodos tiene un significado
especial como un literal de elipsis. La segunda mitad de la lista, los
operadores de asignación aumentada, sirven léxicamente como
delimitadores, pero también realizan una operación.

Los siguientes caracteres ASCII de impresión tienen un significado
especial como parte de otros tokens o son de alguna manera
significativos para el analizador léxico:

   '       "       #       \

Los siguientes caracteres ASCII de impresión no se utilizan en Python.
Su presencia fuera de las cadenas de caracteres y comentarios es un
error incondicional:

   $       ?       `

-[ Notas al pie de página ]-

[1] https://www.unicode.org/Public/11.0.0/ucd/NameAliases.txt
