On 31/03/13 17:30, Murali Mannava wrote:
and preventing me to go further. Can you please tell me what the problem is?
File "C:\Python27\lib\ast.py", line 37, in parse
return compile(source, filename, mode, PyCF_ONLY_AST)
File "", line 0
^
SyntaxError: unexpected EOF while pars
On 31/03/2013 17:30, Murali Mannava wrote:
Hi,
I am trying to execute a program and it's giving the following problem
and preventing me to go further. Can you please tell me what the problem is?
Thank you,
Murali.
Traceback (most recent call last):
File "pwp_client.py", line 58, in
RE
Hi,
I am trying to execute a program and it's giving the following problem and
preventing me to go further. Can you please tell me what the problem is?
Thank you,
Murali.
Traceback (most recent call last):
File "pwp_client.py", line 58, in
RESULTS = client.run_project(models[action] , are
I just discovered the following:
PEP 3134: Exception objects now store their traceback as the __traceback__
attribute. This means
that an exception object now contains all the information pertaining to an
exception, and there
are fewer reasons to use sys.exc_info() (though the latter is not rem
On Wed, Jan 14, 2009 at 12:09 PM, spir wrote:
> Hello,
>
> I rather often use exceptions as information providers at design or debug
> time. A typical use
> of mine is to have a test version of methods that wrap standard version:
>
> def run():
>do stuff
>that may
>raise e
Le Wed, 14 Jan 2009 21:19:11 +0100,
Willi Richert a écrit :
> Hi,
>
> do you observe the same behavior with traceback.format_exc()? I've used that
> always in such situations which worked all the time.
>
> Regards,
> wr
Hello again, Willi & all,
I guess I got the point. I thought that traceb
Hi,
from http://effbot.org/pyref/sys.exc_info.htm:
"The information returned is specific both to the current thread and to the
current stack frame. If the current stack frame is not handling an exception,
the information is taken from the calling stack frame, or its caller, and so
on until a s
Le Wed, 14 Jan 2009 21:19:11 +0100,
Willi Richert a écrit :
> Hi,
>
> do you observe the same behavior with traceback.format_exc()? I've used that
> always in such situations which worked all the time.
>
> Regards,
> wr
Actually yes, for the traceback object returned by sys.exc_info() is None
Hi,
do you observe the same behavior with traceback.format_exc()? I've used that
always in such situations which worked all the time.
Regards,
wr
Am Mittwoch, 14. Januar 2009 18:09:51 schrieb spir:
> Hello,
>
> I rather often use exceptions as information providers at design or debug
> time. A
On Wed, Jan 14, 2009 at 12:09 PM, spir wrote:
> Hello,
>
> I rather often use exceptions as information providers at design or debug
> time. A typical use
> of mine is to have a test version of methods that wrap standard version:
>
> def run():
>do stuff
>that may
>raise e
Hello,
I rather often use exceptions as information providers at design or debug time.
A typical use
of mine is to have a test version of methods that wrap standard version:
def run():
do stuff
that may
raise exc
def testRun():
try:
run()
e
spir wrote:
Hello,
is there a way to read an exception's traceback? Cannot find it in object
attributes. [dir()
shows no traceback, __dict__ is empty.]
You should be able to do that with the traceback module.
Sincerely,
Albert
___
Tutor maillist
Hello,
is there a way to read an exception's traceback? Cannot find it in object
attributes. [dir()
shows no traceback, __dict__ is empty.]
t = "a"
try:
print t[1]
except IndexError, e:
print e
print repr(e)
print dir(e)
print e. __dict__
print e.a
13 matches
Mail list logo
