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

A Python program is read by a *parser*.  Input to the parser is a
stream of *tokens*, generated by the *lexical analyzer* (also known as
the *tokenizer*). This chapter describes how the lexical analyzer
breaks a file into 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.

If no encoding declaration is found, the default encoding is UTF-8.
If the implicit or explicit encoding of a file is UTF-8, an initial
UTF-8 byte-order mark (b'xefxbbxbf') is ignored rather than being a
syntax error.

Si se declara una codificación, Python debe reconocer el nombre de la
codificación (ver Codificaciones estándar). La codificación se utiliza
para todos los análisis léxicos, incluidos las cadenas literales, los
comentarios y los identificadores.


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.

Within the ASCII range (U+0001..U+007F), the valid characters for
identifiers include the uppercase and lowercase letters "A" through
"Z", the underscore "_" and, except for the first character, the
digits "0" through "9". Python 3.0 introduced additional characters
from outside the ASCII range (see **PEP 3131**).  For these
characters, the classification uses the version of the Unicode
Character Database as included in the "unicodedata" module.

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* - explicit list of characters in PropList.txt to
  support backwards compatibility

* *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.

A non-normative HTML file listing all valid identifier characters for
Unicode 15.0.0 can be found at
https://www.unicode.org/Public/15.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
----------------------------

Added in version 3.10.

Some identifiers are only reserved under specific contexts. These are
known as *soft keywords*.  The identifiers "match", "case", "type" and
"_" can syntactically act as keywords in certain contexts, but this
distinction is done at the parser level, not when tokenizing.

As soft keywords, their use in the grammar is possible while still
preserving compatibility with existing code that uses these names as
identifier names.

"match", "case", and "_" are used in the "match" statement. "type" is
used in the "type" statement.

Distinto en la versión 3.12: "type" is now a soft keyword.


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>

Una restricción sintáctica no indicada por estas producciones es que
no se permiten espacios en blanco entre "stringprefix" o "bytesprefix"
y el resto del literal. El conjunto de caracteres de origen se define
mediante la declaración de codificación; es UTF-8 si no se proporciona
una declaración de codificación en el archivo fuente; ver apartado
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.

Both string and bytes literals may optionally be prefixed with a
letter "'r'" or "'R'"; such constructs are called *raw string
literals* and *raw bytes literals* respectively and treat backslashes
as literal characters.  As a result, in raw string literals, "'\U'"
and "'\u'" escapes are not treated specially.

Added in version 3.3: El prefijo "'rb'" de literales de bytes raw se
ha añadido como sinónimo de "'br'".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 f-strings.  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 """.)


2.4.1.1. Escape sequences
~~~~~~~~~~~~~~~~~~~~~~~~~

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 escape       | Significado                       | Notas   |
|===========================|===================================|=========|
| "\"<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)   |
+---------------------------+-----------------------------------+---------+
| "\x*hh*"                  | 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 escape       | Significado                       | Notas   |
|===========================|===================================|=========|
| "\N{*name*}"              | El carácter llamado *name* en la  | (5)     |
|                           | base de datos de Unicode          |         |
+---------------------------+-----------------------------------+---------+
| "\u*xxxx*"                | Carácter con valor hexadecimal de | (6)     |
|                           | 16 bits *xxxx*                    |         |
+---------------------------+-----------------------------------+---------+
| "\U*xxxxxxxx*"            | Carácter con valor hexadecimal de | (7)     |
|                           | 32 bits *xxxxxxxx*                |         |
+---------------------------+-----------------------------------+---------+

Notas:

1. Se puede agregar una barra invertida al final de una línea para
   ignorar la nueva línea:

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

   Se puede lograr el mismo resultado usando triple-quoted strings, o
   paréntesis y string literal concatenation.

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

   Distinto en la versión 3.11: Octal escapes with value larger than
   "0o377" produce a "DeprecationWarning".

   Distinto en la versión 3.12: Octal escapes with value larger than
   "0o377" produce a "SyntaxWarning". In a future Python version they
   will be eventually a "SyntaxError".

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: Unrecognized escape sequences produce a
"DeprecationWarning".

Distinto en la versión 3.12: Unrecognized escape sequences produce a
"SyntaxWarning". In a future Python version they will be eventually a
"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. f-strings
----------------

Added in version 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 | 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 "'}'".

Expressions in formatted string literals are treated like regular
Python expressions surrounded by parentheses, with a few exceptions.
An empty expression is not allowed, and both "lambda"  and assignment
expressions ":=" must be surrounded by explicit parentheses. Each
expression is evaluated in the context where the formatted string
literal appears, in order from left to right.  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). In that case, replacement fields must be closed in a
different line.

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

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.

Distinto en la versión 3.12: Prior to Python 3.12, comments were not
allowed inside f-string replacement fields.

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

Added in version 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()".

The result is then formatted using the "format()" protocol.  The
format specifier is passed to the "__format__()" method of the
expression or conversion result.  An empty string is passed when the
format specifier is omitted.  The formatted result is then included in
the final value of the whole string.

Los especificadores de formato de nivel superior pueden incluir campos
de reemplazo anidados. Estos campos anidados pueden incluir sus
propios campos de conversión y format specifiers, pero no pueden
incluir campos de reemplazo anidados más profundos. El format
specifier mini-language es el mismo que usa el método "str.format()".

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

Reusing the outer f-string quoting type inside a replacement field is
permitted:

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

Distinto en la versión 3.12: Prior to Python 3.12, reuse of the same
quoting type of the outer f-string inside a replacement field was not
possible.

Backslashes are also allowed in replacement fields and are evaluated
the same way as in any other context:

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

Distinto en la versión 3.12: Prior to Python 3.12, backslashes were
not permitted inside an f-string replacement field.

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

There are three types of numeric literals: integers, floating-point
numbers, and imaginary numbers.  There are no complex literals
(complex numbers can be formed by adding a real number and an
imaginary number).

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. Floating-point literals
------------------------------

Floating-point literals are described by the following lexical
definitions:

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

Note that the integer and exponent parts are always interpreted using
radix 10. For example, "077e010" is legal, and denotes the same number
as "77e10". The allowed range of floating-point literals is
implementation-dependent.  As in integer literals, underscores are
supported for digit grouping.

Some examples of floating-point literals:

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

An imaginary literal yields a complex number with a real part of 0.0.
Complex numbers are represented as a pair of floating-point numbers
and have the same restrictions on their range.  To create a complex
number with a nonzero real part, add a floating-point number to it,
e.g., "(3+4j)".  Some examples of imaginary literals:

   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/15.0.0/ucd/NameAliases.txt
