1. Introducción
***************

Este manual de referencia describe el lenguaje de programación Python.
No pretende ser un tutorial.

Aunque intento ser lo más preciso posible, he optado por utilizar el
Español (N. de T.: del original en inglés "I chose to use English")"
en lugar de especificaciones formales para todo, excepto para la
sintaxis y el análisis léxico. Esto debería hacer el documento más
comprensible para el lector medio, pero dejará espacio para
ambigüedades. En consecuencia, si vienes de Marte y tratas de re
implementar Python sólo a partir de este documento, puede que tengas
que adivinar cosas y, de hecho, probablemente acabarías implementando
un lenguaje bastante diferente. Por otro lado, si estás usando Python
y te preguntas cuáles son las reglas precisas sobre un área particular
del lenguaje, deberías poder encontrarlas aquí. Si te gustaría ver una
definición más formal del lenguaje, quizás podrías ofrecer tu tiempo
--- o inventar una máquina clonadora :-).

Es peligroso añadir muchos detalles de implementación en un documento
de referencia: la implementación puede cambiar y otras
implementaciones del lenguaje pueden funcionar de forma diferente. Por
otro lado, CPython es la implementación de Python más usada (aunque
implementaciones alternativas están ganando soporte), y es importante
mencionar sus detalles particulares especialmente donde la
implementación  impone limitaciones adicionales. Por lo tanto,
encontrarás pequeñas "notas sobre la implementación" repartidas por
todo el texto.

Cada implementación de Python viene con un número de módulos estándar
incorporados. Éstos están documentados en La biblioteca estándar de
Python. Unos pocos de estos módulos son citados cuando interactúan de
forma significativa con la definición del lenguaje.


1.1. Implementaciones alternativas
==================================

Aunque hay una implementación de Python que es, de lejos, la más
popular, hay otras implementaciones alternativas que pueden ser de
particular interés para diferentes audiencias.

Las implementaciones conocidas incluyen:

CPython
   Es la implementación original, y la más mantenida, de Python y está
   escrita en C. Las nuevas características del lenguaje normalmente
   aparecen primero aquí.

Jython
   Python implementado en Java. Esta implementación puede utilizarse
   como lenguaje de scripting para aplicaciones Java, o puede
   utilizarse para crear aplicaciones utilizando las bibliotecas de
   clases Java.  También se utiliza a menudo para crear pruebas para
   bibliotecas Java. Puede encontrar más información en the Jython
   website.

Python para .NET
   Esta implementación, de hecho, usa la implementación CPython, pero
   es una aplicación .NET gestionada y usa librerías .NET. Ha sido
   creada por Brian Lloyd. Para más información ir al sitio web de
   Python for .NET.

IronPython
   Una alternativa de Python para .NET.  A diferencia de Python.NET,
   esta es una implementación completa de Python que genera IL, y
   compila código Python directamente a ensamblados .NET.  Fue creado
   por Jim Hugunin, el creador original de Jython. Para más
   información, consulte el sitio web de IronPython.

PyPy
   Una implementación de Python escrita completamente en Python.
   Soporta varias características avanzadas que no se encuentran en
   otras implementaciones como compatibilidad stackless y un
   compilador Just in Time. Uno de los objetivos del proyecto es
   fomentar la experimentación con el propio lenguaje facilitando la
   modificación del intérprete (ya que está escrito en Python). Puede
   encontrar más información en la página principal del proyecto 'PyPy
   <https://www.pypy.org/>_'.

Cada una de estas implementaciones varía de una forma u otra del
lenguaje tal y como está documentado en este manual, o introduce
información específica más allá de lo cubierto por la documentación
estándar de Python. Por favor, consulte la documentación específica de
cada implementación para saber qué tienes que saber acerca de la
implementación específica que uses.


1.2. Notación
=============

The descriptions of lexical analysis and syntax use a grammar notation
that is a mixture of EBNF and PEG. For example:

   name:   letter (letter | digit | "_")*
   letter: "a"..."z" | "A"..."Z"
   digit:  "0"..."9"

In this example, the first line says that a "name" is a "letter"
followed by a sequence of zero or more "letter"s, "digit"s, and
underscores. A "letter" in turn is any of the single characters "'a'"
through "'z'" and "A" through "Z"; a "digit" is a single character
from "0" to "9".

Each rule begins with a name (which identifies the rule that's being
defined) followed by a colon, ":". The definition to the right of the
colon uses the following syntax elements:

* "name": A name refers to another rule. Where possible, it is a link
  to the rule's definition.

  * "TOKEN": An uppercase name refers to a *token*. For the purposes
    of grammar definitions, tokens are the same as rules.

* ""text"", "'text'": Text in single or double quotes must match
  literally (without the quotes). The type of quote is chosen
  according to the meaning of "text":

  * "'if'": A name in single quotes denotes a keyword.

  * ""case"": A name in double quotes denotes a soft-keyword.

  * "'@'": A non-letter symbol in single quotes denotes an "OP" token,
    that is, a delimiter or operator.

* "e1 e2": Items separated only by whitespace denote a sequence. Here,
  "e1" must be followed by "e2".

* "e1 | e2": A vertical bar is used to separate alternatives. It
  denotes PEG's "ordered choice": if "e1" matches, "e2" is not
  considered. In traditional PEG grammars, this is written as a slash,
  "/", rather than a vertical bar. See **PEP 617** for more background
  and details.

* "e*": A star means zero or more repetitions of the preceding item.

* "e+": Likewise, a plus means one or more repetitions.

* "[e]": A phrase enclosed in square brackets means zero or one
  occurrences. In other words, the enclosed phrase is optional.

* "e?": A question mark has exactly the same meaning as square
  brackets: the preceding item is optional.

* "(e)": Parentheses are used for grouping.

The following notation is only used in lexical definitions.

* ""a"..."z"": Two literal characters separated by three dots mean a
  choice of any single character in the given (inclusive) range of
  ASCII characters.

* "<...>": A phrase between angular brackets gives an informal
  description of the matched symbol (for example, "<any ASCII
  character except "\">"), or an abbreviation that is defined in
  nearby text (for example, "<Lu>").

Some definitions also use *lookaheads*, which indicate that an element
must (or must not) match at a given position, but without consuming
any input:

* "&e": a positive lookahead (that is, "e" is required to match)

* "!e": a negative lookahead (that is, "e" is required *not* to match)

The unary operators ("*", "+", "?") bind as tightly as possible; the
vertical bar ("|") binds most loosely.

White space is only meaningful to separate tokens.

Rules are normally contained on a single line, but rules that are too
long may be wrapped:

   literal: stringliteral | bytesliteral
            | integer | floatnumber | imagnumber

Alternatively, rules may be formatted with the first line ending at
the colon, and each alternative beginning with a vertical bar on a new
line. For example:

   literal:
      | stringliteral
      | bytesliteral
      | integer
      | floatnumber
      | imagnumber

This does *not* mean that there is an empty first alternative.


1.2.1. Lexical and Syntactic definitions
----------------------------------------

There is some difference between *lexical* and *syntactic* analysis:
the *lexical analyzer* operates on the individual characters of the
input source, while the *parser* (syntactic analyzer) operates on the
stream of *tokens* generated by the lexical analysis. However, in some
cases the exact boundary between the two phases is a CPython
implementation detail.

The practical difference between the two is that in *lexical*
definitions, all whitespace is significant. The lexical analyzer
discards all whitespace that is not converted to tokens like
"token.INDENT" or "NEWLINE". *Syntactic* definitions then use these
tokens, rather than source characters.

This documentation uses the same BNF grammar for both styles of
definitions. All uses of BNF in the next chapter (Análisis léxico) are
lexical definitions; uses in subsequent chapters are syntactic
definitions.
