Categoría: Sin categoría Página 49 de 51

Una recursión infinita casi siempre hará que el programa se ejecute un rato y luego provoque un error de Máximum recursión depth exceeded.

Si sospecha que una función o un método esta causando una recursión infinita, comience por asegurarse de que hay un caso básico. En otras palabras, debería haber una condición que haga que la función devuelva un valor sin hacer otra llamada recursiva. Si no, necesita revisar el algoritmo y encontrar ese caso básico.

Si hay un caso básico pero el programa no parece llegar hasta el, añada una sentencia print que imprima los parámetros al principio de la función o método.

Cuando ahora ejecute el programa, vera unas pocas líneas cada vez que se invoque la función o método y allí vera los parámetros. Si los parámetros no se acercan al caso básico, eso le dará alguna idea de por que no lo hace.

Si no esta seguro de que curso sigue el flujo de ejecución en su programa, añada sentencias print al principio de cada función con un mensaje como entrando en la función tururu“, donde tururu es el nombre de la función.

Cuando ahora ejecute el programa, imprimirá una traza de cada función a medida que las vaya invocando.

Si algo va mal durante la ejecución, Python imprime un mensaje que incluye el nombre de la excepción, la línea del programa donde sucedió el problema y una traza inversa.

La traza inversa identifica la función que se está ejecutando ahora y la función que invocó a esta, y luego la función que invocó a ésa, y así sucesivamente. En otras palabras, traza la ruta de las llamadas a las funciones que le llevaron a donde se encuentra. También incluye los números de las líneas de sus archivos donde suceden todas esas llamadas.

El primer paso es examinar el lugar del programa donde sucede el error y ver si puede adivinar lo que sucedió. Estos son algunos de los errores en tiempo de ejecución más comunes:

NameError: Está intentando usar una variable que no existe en el entorno actual. Recuerde que las variables locales son locales. No puede hacer referencia a ellas desde fuera de la función en la que se definen.

TypeError: Hay varias causas posibles:

Está intentando usar un valor de forma inadecuada.

Ejemplo: usar como índice para una cadena, lista o tupla algo que no es un entero.

• Hay una discrepancia entre los elementos de una cadena de formato y los elementos pasados para la conversión. Esto puede ocurrir tanto si el numero de elementos no coincide como si se solicita una conversión no válida.
• Está pasando un numero erróneo de argumentos a una función o método. Con los métodos, fíjese en la definición de los métodos y compruebe que el primer parámetro es self. Luego fíjese en la invocación del método; asegúrese de que está invocando el método sobre un objeto del tipo adecuado y dándole correctamente el resto de argumentos.

KeyError: Está tratando de acceder a un elemento de un diccionario con una clave que no está en el diccionario.

AttributeError: Está intentando acceder a un atributo o método que no existe.

IndexError: El índice que está usando para acceder a una lista, cadena o tupla es mayor que su longitud menos uno. Justo antes de donde aparece el error,
añada una sentencia print que muestre el valor del índice y la longitud del vector.

• Es correcto el tamaño del vector?
• Tiene el índice un valor correcto?

Uno de los problemas de usar sentencias print para la depuración es que puede terminar enterrado en información.

Hay dos formas de atajar el problema:

• Simplificar la salida
• Simplificar el programa.

Para simplificar la salida, puede eliminar o comentar (convertir en comentarios)

las sentencias print que no sean de ayuda, o combinarlas, o dar a la salida un formato que la haga mas comprensible.

Para simplificar el programa puede hacer varias cosas. Primero, reducir la escala del problema en el que esta trabajando el programa.

Por ejemplo, si esta ordenando un vector, ordene un vector pequeño. Si el programa acepta entradas del usuario, dele la entrada mas simple que provoque el problema.

Segundo, limpie el programa. Elimine el código muerto y reorganice el programa para hacerlo tan legible como sea posible.

Por ejemplo, si sospecha que el problema esta en una parte del programa con un anidamiento muy profundo, pruebe a reescribir esa parte con una estructura mas simple. Si sospecha de una función grande, trate de trocearla en funciones menores y pruébelas separadamente.

El proceso de encontrar el caso mínimo de prueba le llevara a menudo al error.

Si se encuentra con que un programa funciona en una situación pero no en otra, eso le dará una pista sobre lo que ocurre.

De forma parecida, la reescritura de una porción de código puede ayudarle a encontrar errores sutiles. Si hace un cambio que a usted le parece que no afecta al programa, pero sí lo hace, le dará una pista.

En cierto modo, los errores semánticos son los mas difíciles de corregir, porque el compilador y el sistema de ejecución no proporcionan información sobre lo que va mal. Solo usted sabe lo que se supone que debe hacer el programa, y solo
usted sabe que no lo esta haciendo.

El primer paso es hacer una conexión entre el texto del programa y el compro- atamiento que esta usted viendo. Necesita una hipótesis sobre lo que realmente esta haciendo el programa. Una de las dificultades que nos encontramos para ello es la alta velocidad de los computadores.

A menudo desearía ralentizar el programa a una velocidad humana, y con algunos programas depuradores podrá hacerlo. Pero el tiempo que lleva colocar unas sentencias print en los lugares adecuados suele ser menor que el que lleva configurar el depurador, poner y quitar puntos de interrupción y hacer caminar el programa hasta donde se produce el error.

Debería hacerse estas preguntas:

¿Hay algo que se supone que debería hacer el programa pero que no parece suceder? Busque la sección del código que realiza esa función y asegúrese de que se ejecuta cuando debería.

¿Ocurre algo que no debería? Busque el programa que realiza esa función y vea si se ejecuta cuando no debe.

¿Hay una sección de código que causa un efecto que no esperaba? asegúrese de que entiende el código en cuestión, especialmente si incluye invocaciones de funciones o métodos de otros módulos de Python. Lea la documentación de las funciones que invoca. Pruébelas escribiendo casos de prueba simples y comprobando el resultado.

Para programar necesitara tener un modelo mental de como funcionan los programas. Si escribe un programa que no hace lo que espera de el, muchas veces el problema no estará en el programa, sino en su modelo mental.

La mejor manera de corregir su modelo mental es dividiendo el programa en sus componentes (normalmente las funciones y métodos) y probando cada componente de forma independiente. Una vez que encuentre la discrepancia entre su modelo y la realidad, podrá solucionar el problema.

Por supuesto, debería ir haciendo y probando componentes tal como desarrolla el programa.

Si encuentra un problema, solo habrá una pequeña cantidad de código nuevo del que no sabe si esta correcto.

Esta bien escribir expresiones complejas mientras sean legibles, pero pueden ser difíciles de depurar. Suele ser una buena idea dividir una expresión compleja en una serie de asignaciones de variables temporales.

Por ejemplo:

   1: self.manos[i].agregaCarta (self.manos[

   2: self.encuentraVecino(i)].darCarta())

Puede reescribirse como:

   1: vecino = self.encuentraVecino (i)

   2: cartaElegida = self.manos[vecino].darCarta()

   3: self.manos[i].agregaCarta (cartaElegida)

Version 1.1, March 2000

Copyright °c 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.

The purpose of this License is to make a manual, textbook, or other written do-
cument free” in the sense of freedom: to assure everyone the e®ective freedom
to copy and redistribute it, with or without modifying it, either commercially
or noncommercially. Secondarily, this License preserves for the author and pu-
blisher a way to get credit for their work, while not being considered responsible
for modi¯cations made by others.

This License is a kind of copyleft,” which means that derivative works of the
document must themselves be free in the same sense. It complements the GNU
General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software,
because free software needs free documentation: a free program should come
with manuals providing the same freedoms that the software does. But this

License is not limited to software manuals; it can be used for any textual work,
regardless of subject matter or whether it is published as a printed book. We
recommend this License principally for works whose purpose is instruction or
reference.

This License applies to any manual or other work that contains a notice placed
by the copyright holder saying it can be distributed under the terms of this Li-
cense. The Document,” below, refers to any such manual or work. Any member
of the public is a licensee, and is addressed as you.”
A Modi¯ed Version” of the Document means any work containing the Docu-
ment or a portion of it, either copied verbatim, or with modi¯cations and/or
translated into another language.
A Secondary Section” is a named appendix or a front-matter section of the
Document that deals exclusively with the relationship of the publishers or aut-
hors of the Document to the Document’s overall subject (or to related matters)
and contains nothing that could fall directly within that overall subject. (For
example, if the Document is in part a textbook of mathematics, a Secondary
Section may not explain any mathematics.) The relationship could be a matter
of historical connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical, or political position regarding them.
The Invariant Sections” are certain Secondary Sections whose titles are de-
signated, as being those of Invariant Sections, in the notice that says that the
Document is released under this License.
The Cover Texts” are certain short passages of text that are listed, as Front-
Cover Texts or Back-Cover Texts, in the notice that says that the Document is
released under this License.
A Transparent” copy of the Document means a machine-readable copy, repre-
sented in a format whose speci¯cation is available to the general public, whose
contents can be viewed and edited directly and straightforwardly with generic
text editors or (for images composed of pixels) generic paint programs or (for
drawings) some widely available drawing editor, and that is suitable for input to
text formatters or for automatic translation to a variety of formats suitable for
input to text formatters. A copy made in an otherwise Transparent ¯le format
whose markup has been designed to thwart or discourage subsequent modi¯ca-
tion by readers is not Transparent. A copy that is not Transparent” is called
Opaque.”

Examples of suitable formats for Transparent copies include plain ASCII wit-
hout markup, Texinfo input format, LATEX input format, SGML or XML using
a publicly available DTD, and standard-conforming simple HTML designed for
human modi¯cation. Opaque formats include PostScript, PDF, proprietary for-
mats that can be read and edited only by proprietary word processors, SGML
or XML for which the DTD and/or processing tools are not generally availa-
ble, and the machine-generated HTML produced by some word processors for
output purposes only.
The Title Page” means, for a printed book, the title page itself, plus such
following pages as are needed to hold, legibly, the material this License requires
to appear in the title page. For works in formats which do not have any title
page as such, Title Page” means the text near the most prominent appearance
of the work’s title, preceding the beginning of the body of the text.