with para org liclipse for development python unit-testing debugging pydev python-2.7

python - para - los puntos de corte pydev no funcionan



pydev para netbeans (5)

Estoy trabajando en un proyecto que usa python 2.7.2, sqlalchemy 0.7, unittest, eclipse 3.7.2 y pydev 2.4. Estoy estableciendo puntos de interrupción en archivos de Python (archivos de prueba de unidad), pero se ignoran por completo (antes, en algún punto, funcionaron). Por ahora, actualicé todo el software relacionado (ver arriba), comencé nuevos proyectos, jugué con la configuración, hipnoté mi pantalla, pero nada funciona.

La única idea que obtuve de una publicación es que tiene algo que ver con el cambio de algunos nombres de archivo .py a minúsculas.

¿Alguien tiene alguna idea?

agregado: Incluso instalé la versión aptana de eclipse y copié los archivos .py en el mismo resultado; los puntos de interrupción aún se ignoran.

aún no hay progreso: he cambiado un código que podría considerarse inusual y lo reemplacé con una solución más directa.

algo más de información: probablemente tiene algo que ver con el módulo unittest:

  • puntos de interrupción en mis archivos que definen el trabajo de las suites de prueba,
  • puntos de interrupción en los archivos unittest estándar en sí mismos funcionan
  • puntos de interrupción en mis métodos de prueba en las clases derivadas de unittest.TestCase no funcionan
  • puntos de interrupción en mi código que se prueba en los casos de prueba no funcionan
  • en algún momento antes de que pudiera definir puntos de interrupción en funcionamiento en los métodos de prueba o el código que se está probando
  • Algunas cosas que cambié después de eso son: empecé a usar suites de prueba, cambié algunos nombres de archivo a minúsculas, ...
  • este problema también ocurre si mi código funciona sin excepciones o fallas de prueba.

lo que ya probé es:

  • eliminar archivos .pyc
  • definir nuevo proyecto y copiar solo archivos .py a él
  • reiniciado varias veces en el medio
  • actualizado a eclipse 3.7.2
  • instalado el último pydev en eclipse 3.7.2
  • cambiar a aptana (y volver)
  • eliminó el código que ''manualmente'' agregó clases a mi módulo
  • jugueteado con algunas configuraciones

lo que aún puedo hacer es:

  • Empiezo un nuevo proyecto con mi código, empiezo a eliminar / cambiar el código hasta que los puntos de interrupción funcionen y una especie de caja negra averigüe si esto tiene algo que ver con alguna parte de mi código
  • ¿Alguien tiene alguna idea de lo que podría causar estos problemas o cómo podrían resolverse?
  • ¿Hay algún otro lugar donde pueda buscar una solución?
  • ¿Los desarrolladores pydev analizan las preguntas en stackoverflow?
  • ¿Hay alguna versión anterior de pydev que pueda probar?

He estado trabajando con pydev / eclipse durante mucho tiempo y funciona bien para mí, pero sin depuración forzé a cambiar IDE.

En respuesta a las preguntas de Fabio a continuación:

  • La versión de Python es 2.7.2,
  • El sys.gettrace da None (pero no tengo idea de qué podría influir en mi código)
  • Este es el resultado del depurador después de cambiar los parámetros sugeridos:

depurador pydev:

starting (''Executing file '', ''D://.eclipse//org.eclipse.platform_3.7.0_248562372//plugins//org.python.pydev.debug_2.4.0.2012020116//pysrc//runfiles.py'') (''arguments:'', "[''D:////.eclipse////org.eclipse.platform_3.7.0_248562372////plugins////org.python.pydev.debug_2.4.0.2012020116////pysrc////runfiles.py'', ''D:////Documents////Code////Eclipse////workspace////sqladata////src////unit_test.py'', ''--port'', ''49856'', ''--verbosity'', ''0'']") (''Connecting to '', ''127.0.0.1'', '':'', ''49857'') (''Connected.'',) (''received command '', ''501/t1/t1.1'') sending cmd: CMD_VERSION 501 1 1.1 sending cmd: CMD_THREAD_CREATE 103 2 <xml><thread name="pydevd.reader" id="-1"/></xml> sending cmd: CMD_THREAD_CREATE 103 4 <xml><thread name="pydevd.writer" id="-1"/></xml> (''received command '', ''111/t3/tD://Documents//Code//Eclipse//workspace//sqladata//src//testData.py/t85/t**FUNC**testAdjacency/tNone'') Added breakpoint:d:/documents/code/eclipse/workspace/sqladata/src/testdata.py - line:85 - func_name:testAdjacency (''received command '', ''122/t5/t;;'') Exceptions to hook : [] (''received command '', ''124/t7/t'') (''received command '', ''101/t9/t'') Finding files... done. Importing test modules ... testAtomic (testTypes.TypeTest) ... ok testCyclic (testTypes.TypeTest) ...

El resto es resultado de la prueba unitaria.

Continuando con la respuesta de Fabio parte 2:

He agregado el código al inicio del programa y el depurador deja de funcionar en la última línea de seguir el método en sqlalchemy / orm / attributes.py (es un descriptor, pero ¿cómo o si interfiere con la depuración está más allá de mi conocimiento actual):

clase InstrumentedAttribute (QueryableAttribute): "" "Atributo instrumentado vinculado a clase que agrega métodos de descriptor." ""

def __set__(self, instance, value): self.impl.set(instance_state(instance), instance_dict(instance), value, None) def __delete__(self, instance): self.impl.delete(instance_state(instance), instance_dict(instance)) def __get__(self, instance, owner): if instance is None: return self dict_ = instance_dict(instance) if self._supports_population and self.key in dict_: return dict_[self.key] else: return self.impl.get(instance_state(instance),dict_) #<= last line of debugging

A partir de ahí, el depurador entra en el método __getattr__ de una de mis propias clases, derivado de una clase declarative_base () de sqlalchemy.

Probablemente resuelto (aunque no entendido):

El problema parecía ser que el __getattr__ mencionado anteriormente, creaba algo similar a la recursión infinita, sin embargo, el programa / unittest / sqlalchemy se recuperaba sin informar ningún error. No entiendo el código sqlalchemy lo suficiente como para entender por qué se __getattr__ método __getattr__ .
Cambié el método __getattr__ para llamar a super para el nombre de atributo para el que ocurrió la recursión (muy probablemente no sea mi solución final) y el problema del punto de interrupción parece haber desaparecido. Si puedo formular el problema de manera uniforme, probablemente intentaré obtener más información sobre el grupo de noticias google sqlalchemy o, al menos, comprobaré si mi solución es robusta.

Gracias a Fabio por su apoyo, la función trace_func () identificó el problema para mí.

Intenta eliminar el archivo .pyc correspondiente (compilado) y luego ejecuta. También a veces me he dado cuenta de que estaba ejecutando más de una instancia de un programa ... lo cual confundió a pydev. Definitivamente también he visto esto antes. Muchas veces

Llegando tarde a la conversación, pero por si acaso eso ayuda. Acabo de encontrarme con un problema similar y descubrí que el depurador es muy particular con respecto a qué líneas considera "ejecutables" y disponibles para romper.

Si está utilizando continuaciones de línea o expresiones de varias líneas (por ejemplo, dentro de una lista), coloque el punto de interrupción en la última línea de la instrucción.

Espero que ayude.

Parece realmente extraño ... Necesito más información para diagnosticar mejor el problema:

Abra / plugins / org.python.pydev.debug / pysrc / pydevd_constants.py y cambie

DEBUG_TRACE_LEVEL = 3 DEBUG_TRACE_BREAKPOINTS = 3

ejecuta tu caso de uso con el problema y agrega el resultado a tu pregunta ...

Además, podría ser que, por algún motivo, la instalación de depuración se reinicie en alguna biblioteca que use o en su código, por lo tanto, haga lo siguiente: en el mismo lugar donde colocaría el punto de interrupción:

import sys print ''current trace function'', sys.gettrace()

(Nota: cuando se ejecute en el depurador, se esperaría que la función de rastreo sea algo así como: <bound method PyDB.trace_dispatch of <__main__.PyDB instance at 0x01D44878>> )

Además, publique qué versión de Python está usando.

Respuesta parte 2:

El hecho de que sys.gettrace () devuelva None es probablemente el problema real ... Conozco algunas librerías externas que entran en juego con él (es decir: DecoratorTools - léase: http://pydev.blogspot.com/2007/06/why-cant-pydev-debugger-work-with.html ) e incluso han visto errores de Python y extensiones compiladas romperlo ...

Aún así, la razón más común por la que se rompe es probablemente porque Python desactivará silenciosamente el rastreo (y por lo tanto el depurador) cuando una recursión arroje un error de desbordamiento de la pila (es decir: RuntimeError: se excedió la profundidad máxima de recursión).

Probablemente pueda poner un punto de interrupción al principio de su programa y pasar al depurador hasta que deje de funcionar.

O tal vez más simple es lo siguiente: agregue el código siguiente al comienzo de su programa y vea qué tan lejos va con la impresión ... Lo último que se imprime es el código justo antes de que se rompiera (por lo tanto, podría poner un punto de interrupción en la última línea impresa sabiendo que debería ser la última línea donde funcionaría): tenga en cuenta que si se trata de un programa grande, la impresión puede llevar mucho tiempo; incluso puede ser más rápido imprimir en un archivo en lugar de en una consola (como como cmd, bash o eclipse) y luego abrir ese archivo (solo redirigir la impresión del ejemplo a un archivo).

import sys def trace_func(frame, event, arg): print ''Context: '', frame.f_code.co_name, ''/tFile:'', frame.f_code.co_filename, ''/tLine:'', frame.f_lineno, ''/tEvent:'', event return trace_func sys.settrace(trace_func)

Si aún no puede resolverlo, publique más información sobre los resultados obtenidos ...

Nota: una solución temporal hasta que no encuentre el lugar real está usando:

import pydevd;pydevd.settrace()

en el lugar donde pondría el punto de interrupción - de esa forma tendría un punto de interrupción en el código que definitivamente debería funcionar, ya que forzará la configuración del rastreo en ese punto (es muy similar a la depuración remota: http://pydev.org/manual_adv_remote_debugger.html excepto que como el depurador ya estaba conectado anteriormente, realmente no tienes que iniciar el depurador remoto, solo haz el settrace para emular un punto de interrupción)

Se encontró con una situación similar ejecutando una aplicación django en Eclipse / pydev. Lo que sucedía era que el código que se estaba ejecutando era el que estaba instalado en mi Virtualenv, no mi código fuente. Eliminé mi proyecto de mis paquetes de sitio env virtuales, reinicié el django en el depurador eclipse / pydev y todo estaba bien.

Tenía síntomas similares. Resultó que la secuencia de importación de mi módulo estaba redireccionando mi módulo python de punto de entrada porque una biblioteca binaria (que no era de Python) tenía que cargarse dinámicamente, es decir, LD_LIBRARY_PATH se restablecía dinámicamente. No sé por qué esto hace que el depurador ignore los puntos de corte posteriores. Quizás la llamada a rexec no especifica depuración = verdadera; debe especificar debug = true / false en función del estado del contexto de llamada?

Intente configurar un punto de interrupción en su primera declaración de importación para saber si está s (tep) entrando o n (ext) superando las importaciones. Cuando quería "siguiente" sobre la importación de 3rdparty que requería la carga dinámica de lib, el intérprete de depuración simplemente continuaría pasando todos los puntos de interrupción.