I would like to know if there is an easy way to prevent Python tracebacks to print the full path of files when there is an error. For example, the traceback below prints the absolute path of the file generating the exception:
Traceback (most recent call last):
File "C:/Users/user/Documents/project/project_align/src/main.py", line 62, in <module>
raise Exception
Exception
I wish it to just print the relative path instead: project_align/src/main.py
Is there a configuration parameter somewhere to force this?
I do not know if there is a flag to do this, but if you really want to, you can override sys.excepthook with your own function, within which you can create a TracebackException, remove all filenames from the frame summaries, and format and print it.
import os
import sys
import traceback
def handler(_exception_type, _value, t):
exc = traceback.TracebackException(_exception_type, _value, t)
# replace file names for each frame summary
for frame_summary in exc.stack:
frame_summary.filename = os.path.relpath(frame_summary.filename)
# format and print the exception
print(''.join(exc.format()), file=sys.stderr)
sys.excepthook = handler
def crashes_hard():
print(1 / 0)
def crashes():
crashes_hard()
crashes()
The output is
Traceback (most recent call last):
File "scratch_1.py", line 31, in <module>
crashes()
File "scratch_1.py", line 28, in crashes
crashes_hard()
File "scratch_1.py", line 24, in crashes_hard
print(1 / 0)
ZeroDivisionError: division by zero
The original output is
Traceback (most recent call last):
File "/home/abhijat/.config/.../scratches/scratch_1.py", line 31, in <module>
crashes()
File "/home/abhijat/.config/.../scratches/scratch_1.py", line 28, in crashes
crashes_hard()
File "/home/abhijat/.config/.../scratches/scratch_1.py", line 24, in crashes_hard
print(1 / 0)
ZeroDivisionError: division by zero
Related
Consider the following Python program:
code = """
def test():
1/0
"""
filename = "<test>"
c = compile(code, filename, 'exec')
exec(c)
import linecache
linecache.cache[filename] = (len(code), None, code.splitlines(keepends=True), filename)
import traceback
print("Traceback from the traceback module:")
print()
try:
test()
except:
traceback.print_exc()
print()
print("Regular traceback:")
print()
test()
I am dynamically defining a function that raises an exception and adding it to the linecache. The output of the code is
Traceback from the traceback module:
Traceback (most recent call last):
File "test.py", line 20, in <module>
test()
File "<test>", line 3, in test
1/0
ZeroDivisionError: division by zero
Regular traceback:
Traceback (most recent call last):
File "test.py", line 28, in <module>
test()
File "<test>", line 3, in test
ZeroDivisionError: division by zero
If I then get a traceback from that function using the traceback module, the line of code from the function is shown (the 1/0 part of the first traceback). But if I just let the code raise an exception and get the regular traceback from the interpreter, it doesn't show the code.
Why doesn't the regular interpreter traceback use the linecache? Is there a way to make the code appear in regular tracebacks?
The default sys.excepthook uses a separate, C-level implementation of traceback printing, not the traceback module. (Perhaps this is so it still works even if the system is too borked to use traceback.py.) The C implementation doesn't try to use linecache. You can see the code it uses to retrieve source lines in _Py_DisplaySourceLine.
If you want tracebacks to use the traceback module's implementation, you could replace sys.excepthook with traceback.print_exception:
import sys
import traceback
sys.excepthook = traceback.print_exception
I've still not been able to resolve this problem, after working on it for a week.
I'm thinking of giving up and just running theano on a virutal machine; there just doesn't seem to be any support out there for Windows 10!
Or am I wrong; is there an easy fix to this?
>>> import theano
Traceback (most recent call last):
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\lazylinker_c.py", line 75, in <module>
raise ImportError()
ImportError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\lazylinker_c.py", line 92, in <module>
raise ImportError()
ImportError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\cmodule.py", line 1784, in _try_compile_tmp
os.remove(exe_path + ".exe")
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\cturn\\AppData\\Local\\Temp\\try_march_3v6ffkv9.exe'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\__init__.py", line 66, in <module>
from theano.compile import (
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\compile\__init__.py", line 10, in <module>
from theano.compile.function_module import *
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\compile\function_module.py", line 21, in <module>
import theano.compile.mode
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\compile\mode.py", line 10, in <module>
import theano.gof.vm
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\vm.py", line 659, in <module>
from . import lazylinker_c
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\lazylinker_c.py", line 125, in <module>
args = cmodule.GCC_compiler.compile_args()
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\cmodule.py", line 2088, in compile_args
default_compilation_result, default_execution_result = try_march_flag(GCC_compiler.march_flags)
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\cmodule.py", line 1856, in try_march_flag
flags=cflags, try_run=True)
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\cmodule.py", line 2188, in try_compile_tmp
comp_args)
File "C:\Users\cturn\Anaconda3\lib\site-packages\theano\theano\gof\cmodule.py", line 1789, in _try_compile_tmp
err += "\n" + str(e)
TypeError: can't concat bytes to str
Um, can't concat bytes to str? What does this mean?
The error you are experiencing appears to result from another sub-process utilizing the same resources as the script you are attempting to write. Although it sounds trivial, I would recommend making sure that you have admin privileges, or at least privileges to the desired resources, and/or restart your computer to kill the sub-process using that module. You could also look in the task manager and kill any/all other processes using python, but that might take longer.
(This may be the program using the "resource" try_march_3v6ffkv9.exe)
I'm trying to figure out why this
def scanner(fileName, function):
with open(fileName) as file:
for line in file:
function(line)
def toSmallLetters(line):
print line.lower()
def paramin(fileName):
scanner(fileName, toSmallLetters)
if __name__ == "__main__":
import sys
paramin(sys.argv[1])
throws this error:
Traceback (most recent call last):
File "script.py", line 14, in <module>
paramin(sys.argv[1])
IndexError: list index out of range
What's wrong?
You are getting:
Traceback (most recent call last):
File "script.py", line 14, in <module>
paramin(sys.argv[1])
IndexError: list index out of range
because when you run the script you need to supply a parameter, presumably the file name that you want to scan. If the file is called script.py you might run as:
python script.py name-of-file-to-scan
sys module provides access to any command-line arguments via the sys.argv.
Provide argument while running program.
ex:
python script.py file_name
I've build a little internal DSL with python. I'm using assert vor validation. If the end user types a wrong parameter the dsl should report whats wrong. At the moment this looks like this:
Traceback (most recent call last):
File "tests/maskedtimefilter_test/FilterDSL_test.py", line 63, in test_dsl_validation
input(0): self.regular
File "/Users/sh/reetz/pythonpath/maskedtimedata/maskedtimefilter.py", line 885, in __lshift__
kwargs = self.dsl_validation(kwargs)
File "/Users/sh/reetz/pythonpath/maskedtimedata/maskedtimefilter.py", line 1483, in dsl_validation
check_if_valid(parameter)
File "/Users/sh/reetz/pythonpath/maskedtimedata/dsl.py", line 47, in kernel_a
def kernel_a (x): assert isinstance(x, (list, tuple, np.ndarray)), "kernel must be a list."
AssertionError: kernel must be a list.
But the end users are engineers and no computer scientists. Therefore a minimal Traceback is handy. Is it possible to shrink the Traceback to the essential information (where is the failure and what's the cause) like this?:
Traceback (most recent call last):
File "tests/maskedtimefilter_test/FilterDSL_test.py", line 63, in test_dsl_validation
input(0): self.regular
AssertionError: kernel must be a list.
Reluctantly I'd like to use normal prints!
Why not return the traceback data as an array and just work back from that?
import traceback
try:
codethatwillthrowanexception()
except:
exceptiondata = traceback.format_exc().splitlines()
exceptionarray = [exceptiondata[-1]] + exceptiondata[1:-1]
Somewhere in your call stack you can do this:
try:
my_function_that_can_raise_exception()
except Exception: #or AssertionError
import traceback
traceback.print_exc(limit=1)
limit is the depth of how many stack trace entries you want to show. (in your case, 1)
demo:
In [21]: def f():
...: assert False == True, 'Assertion!'
...:
In [22]: try:
...: f()
...: except Exception:
...: import traceback
...: traceback.print_exc(limit=1)
...:
Traceback (most recent call last):
File "<ipython-input-22-78f9db8d5188>", line 2, in <module>
f()
AssertionError: Assertion!
read more at traceback docs.
As the first part of the traceback is just what you called, you could so something simple, like:
try:
input(0): self.regular # base call
except AssertionError as ae: # catch the exception
print(ae) # print out the message
You can print out whatever you think would be useful in the except block.
Alternatively, you could do something more complex with the traceback module.
So I have found an error in a module I am using (which one is unimportant, but if you must know it's geopy.distance)
So I know what I have to do to fix the code, but when I open the .py file and edit it, it acts as if it was not edited!
Here is the error traceback before edited:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Python/2.7/site-packages/geopy-0.95.1-py2.7.egg/geopy/distance.py", line 37, in __init__
kilometers += self.measure(a, b)
File "/Library/Python/2.7/site-packages/geopy-0.95.1-py2.7.egg/geopy/distance.py", line 72, in measure
raise NotImplementedError
NotImplementedError
Here is the error traceback after I edit the file:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Library/Python/2.7/site-packages/geopy-0.95.1-py2.7.egg/geopy/distance.py", line 37, in __init__
kilometers += self.measure(a, b)
File "/Library/Python/2.7/site-packages/geopy-0.95.1-py2.7.egg/geopy/distance.py", line 72, in measure
a, b = Point(a), Point(b)
NotImplementedError
as you can see, I changed it so it would not raise NotImplementedError, but it is still raising it! How is this possible?
Looks like you've edited a .py file, but the user process doesn't have permission to overwrite the .pyc file. The NotImplementedError is still on line 72 according to the .pyc file, but it's displaying the current line 72 from the .py file
Aside: Looks like Distance is an abstract class. You're not supposed to instantiate directly, but one of the subclasses of it. Eg GreatCircleDistance or VincentyDistance
Also notice the last two lines in the file
# Set the default distance formula to the most generally accurate.
distance = VincentyDistance