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

The end of a logical line is represented by the token "NEWLINE".
Statements cannot cross logical line boundaries except where "NEWLINE"
is allowed by the syntax (e.g., between statements in compound
statements). A logical line is constructed from one or more *physical
lines* by following the explicit or implicit *line joining* rules.


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

A physical line is a sequence of characters terminated by one the
following end-of-line sequences:

* the Unix form using ASCII LF (linefeed),

* the Windows form using the ASCII sequence CR LF (return followed by
  linefeed),

* the 'Classic Mac OS' form using the ASCII CR (return) character.

Regardless of platform, each of these sequences is replaced by a
single ASCII LF (linefeed) character. (This is done even inside string
literals.) Each line can use any of the sequences; they do not need to
be consistent within a file.

The end of input also serves as an implicit terminator for the final
physical line.

Formally:

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


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'\xef\xbb\xbf'") 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.

All lexical analysis, including string literals, comments and
identifiers, works on Unicode text decoded using the source encoding.
Any Unicode code point, except the NUL control character, can appear
in Python source.

   source_character:  <any Unicode code point, except NUL>


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',      # Son los
                  'April',   'Mei',      'Juni',       # nombres holandeses
                  'Juli',    'Augustus', 'September',  # para los meses
                  'Oktober', 'November', 'December']   # del año

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

A logical line that contains only spaces, tabs, formfeeds and possibly
a comment, is ignored (i.e., no "NEWLINE" token is generated). During
interactive input of statements, handling of a blank line may differ
depending on the implementation of the read-eval-print loop. In the
standard interactive interpreter, an entirely blank logical line (that
is, one containing not even whitespace or a comment) terminates a
multi-line statement.


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

The indentation levels of consecutive lines are used to generate
"INDENT" and "DEDENT" tokens, using a stack, as follows.

Before the first line of the file is read, a single zero is pushed on
the stack; this will never be popped off again.  The numbers pushed on
the stack will always be strictly increasing from bottom to top.  At
the beginning of each logical line, the line's indentation level is
compared to the top of the stack. If it is equal, nothing happens. If
it is larger, it is pushed on the stack, and one "INDENT" token is
generated.  If it is smaller, it *must* be one of the numbers
occurring on the stack; all numbers on the stack that are larger are
popped off, and for each number popped off a "DEDENT" token is
generated. At the end of the file, a "DEDENT" token is generated for
each number remaining on the stack that is larger than zero.

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

   def perm(l):
           # Calcular la lista de todas las permutaciones 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

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

Except at the beginning of a logical line or in string literals, the
whitespace characters space, tab and formfeed can be used
interchangeably to separate tokens.  Whitespace is needed between two
tokens only if their concatenation could otherwise be interpreted as a
different token. For example, "ab" is one token, but "a b" is two
tokens. However, "+a" and "+ a" both produce two tokens, "+" and "a",
as "+a" is not a valid token.


2.1.10. End marker
------------------

At the end of non-interactive input, the lexical analyzer generates an
"ENDMARKER" token.


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

Besides "NEWLINE", "INDENT" and "DEDENT", the following categories of
tokens exist: *identifiers* and *keywords* ("NAME"), *literals* (such
as "NUMBER" and "STRING"), and other symbols (*operators* and
*delimiters*, "OP"). Whitespace characters (other than logical line
terminators, discussed earlier) are not tokens, but serve to delimit
tokens. Where ambiguity exists, a token comprises the longest possible
string that forms a legal token, when read from left to right.


2.3. Names (identifiers and keywords)
=====================================

"NAME" tokens represent *identifiers*, *keywords*, and *soft
keywords*.

Within the ASCII range (U+0001..U+007F), the valid characters for
names include the uppercase and lowercase letters ("A-Z" and "a-z"),
the underscore "_" and, except for the first character, the digits "0"
through "9".

Names must contain at least one character, but have no upper length
limit. Case is significant.

Besides "A-Z", "a-z", "_" and "0-9", names can also use "letter-like"
and "number-like" characters from outside the ASCII range, as detailed
below.

All identifiers are converted into the normalization form NFKC while
parsing; comparison of identifiers is based on NFKC.

Formally, the first character of a normalized identifier must belong
to the set "id_start", which is the union of:

* Unicode category "<Lu>" - uppercase letters (includes "A" to "Z")

* Unicode category "<Ll>" - lowercase letters (includes "a" to "z")

* Unicode category "<Lt>" - titlecase letters

* Unicode category "<Lm>" - modifier letters

* Unicode category "<Lo>" - other letters

* Unicode category "<Nl>" - letter numbers

* {""_""} - the underscore

* "<Other_ID_Start>" - an explicit set of characters in PropList.txt
  to support backwards compatibility

The remaining characters must belong to the set "id_continue", which
is the union of:

* all characters in "id_start"

* Unicode category "<Nd>" - decimal numbers (includes "0" to "9")

* Unicode category "<Pc>" - connector punctuations

* Unicode category "<Mn>" - nonspacing marks

* Unicode category "<Mc>" - spacing combining marks

* "<Other_ID_Continue>" - another explicit set of characters in
  PropList.txt to support backwards compatibility

Unicode categories use the version of the Unicode Character Database
as included in the "unicodedata" module.

These sets are based on the Unicode standard annex UAX-31. See also
**PEP 3131** for further details.

Even more formally, names are described by the following lexical
definitions:

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

A non-normative listing of all valid identifier characters as defined
by Unicode is available in the DerivedCoreProperties.txt file in the
Unicode Character Database.


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

The following names are used as reserved words, or *keywords* of the
language, and cannot be used as ordinary identifiers.  They must be
spelled exactly as written here:

   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 names are only reserved under specific contexts. These are known
as *soft keywords*:

* "match", "case", and "_", when used in the "match" statement.

* "type", when used in the "type" statement.

These syntactically act as keywords in their specific contexts, but
this distinction is done at the parser level, not when tokenizing.

Como palabras clave suaves, su uso en la gramática es posible sin
dejar de preservar la compatibilidad con el código existente que usa
esos nombres como nombres de identificadores.

Distinto en la versión 3.12: "type" ahora es un palabra clave suave.


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.

In terms of lexical analysis, Python has string, bytes and numeric
literals.

Other "literals" are lexically denoted using keywords ("None", "True",
"False") and the special ellipsis token ("...").


2.5. Literales de cadenas y bytes
=================================

String literals are text enclosed in single quotes ("'") or double
quotes ("""). For example:

   "spam"
   'eggs'

The quote used to start the literal also terminates it, so a string
literal can only contain the other quote (except with escape
sequences, see below). For example:

   'Say "Hello", please.'
   "Don't do that!"

Except for this limitation, the choice of quote character ("'" or """)
does not affect how the literal is parsed.

Inside a string literal, the backslash ("\") character introduces an
*escape sequence*, which has special meaning depending on the
character after the backslash. For example, "\"" denotes the double
quote character, and does *not* end the string:

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

See escape sequences below for a full list of such sequences, and more
details.


2.5.1. Triple-quoted strings
----------------------------

Strings can also be enclosed in matching groups of three single or
double quotes. These are generally referred to as *triple-quoted
strings*:

   """This is a triple-quoted string."""

In triple-quoted literals, unescaped quotes are allowed (and are
retained), except that three unescaped quotes in a row terminate the
literal, if they are of the same kind ("'" or """) used at the start:

   """This string has "quotes" inside."""

Unescaped newlines are also allowed and retained:

   '''This triple-quoted string
   continues on the next line.'''


2.5.2. String prefixes
----------------------

String literals can have an optional *prefix* that influences how the
content of the literal is parsed, for example:

   b"data"
   f'{result=}'

The allowed prefixes are:

* "b": Bytes literal

* "r": Raw string

* "f": Formatted string literal ("f-string")

* "t": Template string literal ("t-string")

* "u": No effect (allowed for backwards compatibility)

See the linked sections for details on each type.

Prefixes are case-insensitive (for example, '"B"' works the same as
'"b"'). The '"r"' prefix can be combined with '"f"', '"t"' or '"b"',
so '"fr"', '"rf"', '"tr"', '"rt"', '"br"', and '"rb"' are also valid
prefixes.

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.


2.5.3. Formal grammar
---------------------

String literals, except "f-strings" and "t-strings", are described by
the following lexical definitions.

These definitions use negative lookaheads ("!") to indicate that an
ending quote ends the literal.

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

Note that as in all lexical definitions, whitespace is significant. In
particular, the prefix (if any) must be immediately followed by the
starting quote.


2.5.4. Secuencias de escape
---------------------------

Unless an '"r"' or '"R"' prefix is present, escape sequences in string
and bytes literals are interpreted according to rules similar to those
used by Standard C.  The recognized escape sequences are:

+----------------------------------------------------+----------------------------------------------------+
| Secuencia de escape                                | Significado                                        |
|====================================================|====================================================|
| "\"<newline>                                       | Ignored end of line                                |
+----------------------------------------------------+----------------------------------------------------+
| "\\"                                               | Backslash                                          |
+----------------------------------------------------+----------------------------------------------------+
| "\'"                                               | Single quote                                       |
+----------------------------------------------------+----------------------------------------------------+
| "\""                                               | Double quote                                       |
+----------------------------------------------------+----------------------------------------------------+
| "\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*"                                           | Octal character                                    |
+----------------------------------------------------+----------------------------------------------------+
| "\x*hh*"                                           | Hexadecimal character                              |
+----------------------------------------------------+----------------------------------------------------+
| "\N{*name*}"                                       | Named Unicode character                            |
+----------------------------------------------------+----------------------------------------------------+
| "\u*xxxx*"                                         | Hexadecimal Unicode character                      |
+----------------------------------------------------+----------------------------------------------------+
| "\U*xxxxxxxx*"                                     | Hexadecimal Unicode character                      |
+----------------------------------------------------+----------------------------------------------------+


2.5.4.1. Ignored end of line
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

   >>> 'Esta cadena no incluirá \
   ... caracteres de barra invertida o nueva linea.'
   'Esta cadena no incluirá caracteres de barra invertida o nueva linea.'

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


2.5.4.2. Escaped characters
~~~~~~~~~~~~~~~~~~~~~~~~~~~

To include a backslash in a non-raw Python string literal, it must be
doubled. The "\\" escape sequence denotes a single backslash
character:

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

Similarly, the "\'" and "\"" sequences denote the single and double
quote character, respectively:

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


2.5.4.3. Octal character
~~~~~~~~~~~~~~~~~~~~~~~~

The sequence "\*ooo*" denotes a *character* with the octal (base 8)
value *ooo*:

   >>> '\120'
   'P'

Up to three octal digits (0 through 7) are accepted.

In a bytes literal, *character* means a *byte* with the given value.
In a string literal, it means a Unicode character with the given
value.

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

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


2.5.4.4. Hexadecimal character
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The sequence "\x*hh*" denotes a *character* with the hex (base 16)
value *hh*:

   >>> '\x50'
   'P'

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

In a bytes literal, *character* means a *byte* with the given value.
In a string literal, it means a Unicode character with the given
value.


2.5.4.5. Named Unicode character
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The sequence "\N{*name*}" denotes a Unicode character with the given
*name*:

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

This sequence cannot appear in bytes literals.

Distinto en la versión 3.3: Support for name aliases has been added.


2.5.4.6. Hexadecimal Unicode characters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

These sequences "\u*xxxx*" and "\U*xxxxxxxx*" denote the Unicode
character with the given hex (base 16) value. Exactly four digits are
required for "\u"; exactly eight digits are required for "\U". The
latter can encode any Unicode character.

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

These sequences cannot appear in bytes literals.


2.5.4.7. Unrecognized escape sequences
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Unlike in Standard C, all unrecognized escape sequences are left in
the string unchanged, that is, *the backslash is left in the result*:

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

Note that for bytes literals, the escape sequences only recognized in
string literals ("\N...", "\u...", "\U...") fall into the category of
unrecognized escapes.

Distinto en la versión 3.6: Secuencias de escape no conocidas producen
un "DeprecationWarning".

Distinto en la versión 3.12: Unrecognized escape sequences produce a
"SyntaxWarning". In a future Python version they will raise a
"SyntaxError".


2.5.5. Bytes literals
---------------------

*Bytes literals* are always prefixed with '"b"' or '"B"'; they produce
an instance of the "bytes" type instead of the "str" type. They may
only contain ASCII characters; bytes with a numeric value of 128 or
greater must be expressed with escape sequences (typically Hexadecimal
character or Octal character):

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

Similarly, a zero byte must be expressed using an escape sequence
(typically "\0" or "\x00").


2.5.6. Raw string literals
--------------------------

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, escape
sequences are not treated specially:

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

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.5.7. f-strings
----------------

Added in version 3.6.

A *formatted string literal* or *f-string* is a string literal that is
prefixed with '"f"' or '"F"'.  These strings may contain replacement
fields, which are expressions delimited by curly braces "{}". While
other string literals always have a constant value, formatted strings
are really expressions evaluated at run time.

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

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. Cada expresión se evalúa en el contexto donde
aparece el literal de cadena, en orden desde la izquierda a la
derecha.  Las expresiones de sustitución pueden contener saltos de
línea en cadenas f de dos y tres comillas y pueden contener
comentarios. Todo lo que viene después de un "#" dentro de un campo de
reemplazo es un comentario (incluso llaves de cerramiento y comillas).
En ese caso, campos de reemplazo deben ser cerrados en una linea
diferente.

   >>> f"abc{a # Es un comentario }"
   ... + 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: Antes de Python 3.12, comentarios no se
permitieron dentro de campos de reemplazo de f-string.

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

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 de
caracteres vacía cuando se omite el especificador de formato. El
resultado formateado se incluye entonces en el valor final de toda la
cadena de caracteres.

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() es equivalente a !r
   "He said his name is 'Fred'."
   >>> width = 10
   >>> precision = 4
   >>> value = decimal.Decimal("12.34567")
   >>> f"result: {value:{width}.{precision}}"  # campos anidados
   'result:      12.35'
   >>> today = datetime(year=2017, month=1, day=27)
   >>> f"{today:%B %d, %Y}"  # utilizando el especificador de formato de fecha
   'January 27, 2017'
   >>> f"{today=:%B %d, %Y}" # utilizando el especificador de formato de fecha y purificación
   'today=January 27, 2017'
   >>> number = 1024
   >>> f"{number:#0x}" # utilizando el especificador de formato de números enteros
   '0x400'
   >>> foo = "bar"
   >>> f"{ foo = }" # conserva espacios en blanco
   " 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" '

Se puede reutilizar el tipo de comilla del f-string exterior dentro de
un campo de reemplazo:

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

Distinto en la versión 3.12: Antes de Python 3.12, no era posible
reutilizar el mismo tipo de comilla del f-string exterior dentro de un
campo de reemplazo.

También se permiten barras invertidas en campos de reemplazo y se
evalúan de la misma manera que cualquier otro contexto:

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

Distinto en la versión 3.12: Antes de Python 3.12, no se permitieron
dentro de una campo de reemplazo f-string.

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.5.8. t-strings
----------------

Added in version 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 and
evaluation rules as formatted string literals, with the following
differences:

* Rather than evaluating to a "str" object, template string literals
  evaluate to a "string.templatelib.Template" object.

* The "format()" protocol is not used. Instead, the format specifier
  and conversions (if any) are passed to a new "Interpolation" object
  that is created for each evaluated expression. It is up to code that
  processes the resulting "Template" object to decide how to handle
  format specifiers and conversions.

* Format specifiers containing nested replacement fields are evaluated
  eagerly, prior to being passed to the "Interpolation" object. For
  instance, an interpolation of the form "{amount:.{precision}f}" will
  evaluate the inner expression "{precision}" to determine the value
  of the "format_spec" attribute. If "precision" were to be "2", the
  resulting format specifier would be "'.2f'".

* When the equals sign "'='" is provided in an interpolation
  expression, the text of the expression is appended to the literal
  string that precedes the relevant interpolation. This includes the
  equals sign and any surrounding whitespace. The "Interpolation"
  instance for the expression will be created as normal, except that
  "conversion" will be set to '"r"' ("repr()") by default. If an
  explicit conversion or format specifier are provided, this will
  override the default behaviour.


2.6. Literales numéricos
========================

"NUMBER" tokens represent numeric literals, of which there are three
types: integers, floating-point numbers, and imaginary numbers.

   NUMBER: integer | floatnumber | imagnumber

The numeric value of a numeric literal is the same as if it were
passed as a string to the "int", "float" or "complex" class
constructor, respectively. Note that not all valid inputs for those
constructors are also valid literals.

Numeric literals do not include a sign; a phrase like "-1" is actually
an expression composed of the unary operator '"-"' and the literal
"1".


2.6.1. Literales enteros
------------------------

Integer literals denote whole numbers. For example:

   7
   3
   2147483647

There is no limit for the length of integer literals apart from what
can be stored in available memory:

   7922816251426433759354395033679228162514264337593543950336

Underscores can be used to group digits for enhanced readability, and
are ignored for determining the numeric value of the literal. For
example, the following literals are equivalent:

   100_000_000_000
   100000000000
   1_00_00_00_00_000

Underscores can only occur between digits. For example, "_123",
"321_", and "123__321" are *not* valid literals.

Integers can be specified in binary (base 2), octal (base 8), or
hexadecimal (base 16) using the prefixes "0b", "0o" and "0x",
respectively. Hexadecimal digits 10 through 15 are represented by
letters "A"-"F", case-insensitive.  For example:

   0b100110111
   0b_1110_0101
   0o177
   0o377
   0xdeadbeef
   0xDead_Beef

An underscore can follow the base specifier. For example, "0x_1f" is a
valid literal, but "0_x1f" and "0x__1f" are not.

Leading zeros in a non-zero decimal number are not allowed. For
example, "0123" is not a valid literal. This is for disambiguation
with C-style octal literals, which Python used before version 3.0.

Formally, integer literals are described by the following lexical
definitions:

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

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


2.6.2. Literales de punto flotante
----------------------------------

Floating-point (float) literals, such as "3.14" or "1.5", denote
approximations of real numbers.

They consist of *integer* and *fraction* parts, each composed of
decimal digits. The parts are separated by a decimal point, ".":

   2.71828
   4.0

Unlike in integer literals, leading zeros are allowed in the numeric
parts. For example, "077.010" is legal, and denotes the same number as
"77.10".

As in integer literals, single underscores may occur between digits to
help readability:

   96_485.332_123
   3.14_15_93

Either of these parts, but not both, can be empty. For example:

   10.  # (equivalent to 10.0)
   .001  # (equivalent to 0.001)

Optionally, the integer and fraction may be followed by an *exponent*:
the letter "e" or "E", followed by an optional sign, "+" or "-", and a
number in the same format as the integer and fraction parts. The "e"
or "E" represents "times ten raised to the power of":

   1.0e3  # (represents 1.0×10³, or 1000.0)
   1.166e-5  # (represents 1.166×10⁻⁵, or 0.00001166)
   6.02214076e+23  # (represents 6.02214076×10²³, or 602214076000000000000000.)

In floats with only integer and exponent parts, the decimal point may
be omitted:

   1e3  # (equivalent to 1.e3 and 1.0e3)
   0e0  # (equivalent to 0.)

Formally, floating-point literals are described by the following
lexical definitions:

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

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


2.6.3. Literales imaginarios
----------------------------

Python has complex number objects, but no complex literals. Instead,
*imaginary literals* denote complex numbers with a zero real part.

For example, in math, the complex number 3+4.2*i* is written as the
real number 3 added to the imaginary number 4.2*i*. Python uses a
similar syntax, except the imaginary unit is written as "j" rather
than *i*:

   3+4.2j

This is an expression composed of the integer literal "3", the
operator '"+"', and the imaginary literal "4.2j". Since these are
three separate tokens, whitespace is allowed between them:

   3 + 4.2j

No whitespace is allowed *within* each token. In particular, the "j"
suffix, may not be separated from the number before it.

The number before the "j" has the same syntax as a floating-point
literal. Thus, the following are valid imaginary literals:

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

Unlike in a floating-point literal the decimal point can be omitted if
the imaginary number only has an integer part. The number is still
evaluated as a floating-point number, not an integer:

   10j
   0j
   1000000000000000000000000j   # equivalent to 1e+24j

The "j" suffix is case-insensitive. That means you can use "J"
instead:

   3.14J   # equivalent to 3.14j

Formally, imaginary literals are described by the following lexical
definition:

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


2.7. Operadores
===============

Los siguientes tokens son operadores:

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


2.8. Delimitadores
==================

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

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

The period can also occur in floating-point and imaginary literals.

A sequence of three periods has a special meaning as an "Ellipsis"
literal:

   ...

The following *augmented assignment operators* serve lexically as
delimiters, but also perform an operation:

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

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:

   $       ?       `
