I am working with pydev (latest version) and the debugger is not working anymore (specifically breakpoints do not work). I get a strange error:
pydev debugger: starting
Traceback (most recent call last):
with no further text. ...
I am working with stackless python 2.7 and pyside (almost latest version). The breakpoints that are not working are not within stackless tasklets.
Anyone know the cause or a fix?
OK, (slightly embarassed) i have had a similar problem in the past, posted here and got extensive help here
I used that post to pinpoint the problem to this method:
def __getattr__(self, name):
if name in self._code_:
func = self.getfunction(name)
setattr(self, name, func)
return func
else:
return super(AtomicProcess, self).__getattr__(name)
I would like to use this or a similar method to set the attribute at the latest possible time (when it is called).I added the super call to possibly fix the problem, but no dice.
Does anyone know what causes the problem in this method?
Does anyone have a fix that achieves the late initialization but avoids the pydev problem?
Also I should mention that my code runs without problem but that the debugger seems to go into some infinite recursion in the method above, recovers and ignores breakpoints after this method.
Cheers, Lars
PS: anyone? Are pydev developers following stackoverflow or is there another place i might try?
It seems it's something as the previous issue although I'm not sure what (if you can pass me the code I can take a look at it, but without it, the only thing I can do is point to the last thread we had).
Keep in mind that if you have a recursion exception, this is something that breaks the Python debugging facility... What you can do as a workaround in the meanwhile is using the remote debugger to improve on that.
I do have a hunch thought:
My guess is that you access something in 'self' which is calling __getattr__ again... (which generates a recursion and breaks the debugger).
Another possible thing: instead of using the 'super' idiom in: super(AtomicProcess, self).__getattr__(name), use the superclass directly: Superclass.__getattr__(self, name)...
Cheers,
Fabio
Related
I am working on some soon-to-be obsolete scientific software written in Python (Enthought Python Distribution, Python 2.7.1, IPython 0.10.1). We need to check if the older results are correct, but with the massive amount of data we have the GUI procedure we need to make working with non-GUI mode. The important piece of code is to save the data:
def _save_button_fired(self):
self.savedata()
In GUI when we click on the button the file is saved correctly. In non-GUI mode, when we do the following:
m.savedata()
the file is created, but a number of errors appear starting with:
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
etc. etc. When I use CTRL+D, select Y to kill the Python, the file is quite surprisingly written correctly. This is suffcient for our needs. However, is there any way to ignore the error and just proceed further with the code? I looked at the forum for solutions but non of them seems to fit my situation. Also, I am not keen on Python, thus would be grateful for a working solution. With many thanks.
You could wrap it in a try/pass :)
try:
self.savedata()
except TypeError:
pass
An alternative to the try/pass solution is contextlib.suppress.
with contextlib.suppress(TypeError):
self.savedata()
Why one over the other?
The context manager slightly shortens the code and significantly clarifies the author's intention to ignore the specific errors. The standard library feature was introduced following a discussion, where the consensus was that: A key benefit here is in the priming effect for readers... The with statement form makes it clear before you start reading the code that certain exceptions won't propagate.
Source: sourcery.ai
This is a novice question.
Consider the below code block :
try:
import os
except ImportError as error:
print " Unable to import buildin module os"
raise error
Do we need to add exception block while importing python built-in modules(like above? What would cause to fail importing a built in module?
Can someone point at python documentation explaining this theory?
Short answer, no.
Longer answer: it doesn't help your program much to catch exceptions that you can't do anything about. Some file is missing -- you can report it, maybe ask the user again, or perhaps it is known that this sometimes happens and you can give a clear error message explaining why. Some API call fails -- maybe it can be retried, or someone needs to receive a message that a service is down.
But something as basic as this... First, it never happens (I've never seen import os fail in twenty years). Second, if that fails, there's nothing your program can usefully do (if this fails, chances are print also fails). And also, the library documentation doesn't say that this is something that can happen.
You have to rely on the basic system working. Only catch exceptions when it is known that they could be raised and you have a way to deal with them.
There are a couple of reasons that the code in the question is pretty much pointless.
First of all, it does not add any new information. The error is just reraised. The printout adds no new information that isn't already in the error and stack trace.
Second, as #RemcoGerlich's answer points out, you are asking specifically about builtin modules. It would make sense to react to the absence of an optional module by either finding a replacement or turning off program features, but there's nothing much you can do in response to your platform being broken.
Failure of builtin imports is never addressed in the documentation explicitly to the best of my knowledge. Builtin module imports can fail for any of the reasons a normal import can fail. Builtins are a collection of Python files and C-extensions (in CPython at least). Modifying, replacing, deleting any of these files can lead to anything from import failures to the interpreter not starting up at all. Setting the wrong file permissions can have a similar effect.
I find it hard to explain my problem as the problem is not within the code itself. If you need more input to understand the following better, please let me know.
I'm using ArcGIS to call a bunch of python scripts, one after another. The scripts use the same class by importing it, or inherit from it. To initialize the class I often use the same name. I have no idea how the communication between ArcGIS and python is implemented. But I noticed that my scripts are not always behaving like they should. I suppose that the reference to the object still exists (even though the script the object was created with has finished) when I call the second script.
First of all: How can I make sure my suspicion is true?
Secondly, if this is the case: is it a good idea to destroy all references to all objects using del or __del__? What is the best way to do this?
Trace tracing your code and walking through it with a debugger? Quickest way to tell if it's accessing correct code. Python Debugger
If you read the documentation, what you want to do is use a break point to make sure code reaches that point in code.
This is the syntax with the debugger.
b(reak) [[filename:]lineno | function[, condition]]
I'm coding using Python and Pyglet, and, as I just have starting the script, it is full of errors, which is normal.
What is less normal is that those errors don't stop execution of the script, even if they are 'basic python' errors. It isn't very bothersome, but a little, since it makes me outsee some errors.
For example, I got :
AttributeError: 'Win32EventLoop' object has no attribute '_next_idle_time'
(by the way, I don't know what this one means. It isn't the main subject of my thread but I'd gladly get answers for this one)
or :
IndexError: list index out of range
(A stupid bug I solved, but it should have stopped the script).
I use Eclipse + pydev, and never experienced that before. It may be pyglet related because it happened with my first pyglet attemps (before, I used pygame).
Thanks for answers,
Fred
Your GUI application is probably running in some kind of loop. This event loop is catching exceptions for You and printing them out.
I recommend writing Your code the way You can unit-test small parts of your program e.g. classes or functions outside of the framework and then glue them together as GUI application. This work-flow will guarantee that you haven't overseen simple bugs just because mindlessly throwing new code into more-or-less working pile of existing code ;)
Read about TDD ;)
I'm using the Weblogic Scripting Tool aka WLST, a Python-based shell environment, to programmatically edit variables in Plan.xml files for projects to be deployed to the Weblogic server. I can get as far as getting an instance of the WLSTPlan Object, and can run getVariables and other methods to check that it is populated and view its contents. However, when I try to call the setVariable method, I get an AttributeError, which to my limited understanding means the method doesn't exist:
wls:/UoADevDomain/serverConfig> plan.setVariable("foo", "bar")
Traceback (innermost last):
File "<console>", line 1, in ?
AttributeError: setVariable
As the docs linked above (which I checked are the right version) show, this method definitely should exist, and other methods listed in the same doc work. I'm not sure if this is an issue with Weblogic or with my understanding of Python, but either way it's beyond me. I tried using the dir() function to list the plan object's attributes, but it returned an empty set so I guess that trick doesn't work in this environment.
Can anyone suggest how to go about diagnosing this problem, or better still fixing it?
Using javap and looking for setters on the WLSTPlan bean shows only the following setter
void setVariableValue(java.lang.String, java.lang.String);
Could be a typo in the docs. Can you try 'setVariableValue' instead.
The documentation is rather unclear, but from reading between the lines, it looks like setVariable is a method that you invoke on a VariableBean.
I'd try using the following:
plan.createVariable("foo").setVariable("foo", "bar");
(that's without having tested the code, though)