Message99679
I noticed the same behavior today.
Let's consider a test case using my python script "version_check.py" (attached).
Normally the script does the following on my Ubuntu 9.10 box:
# Python 2.6 example:
mike@ebx2009:~/test$ which python
/usr/bin/python
mike@ebx2009:~/test$ python version_check.py
2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
[GCC 4.4.1]
# Python 3.1 example:
mike@ebx2009:~/test$ which python3
/usr/local/bin/python3
mike@ebx2009:~/test$ python3 version_check.py
3.1.1 (r311:74480, Feb 7 2010, 16:32:28)
[GCC 4.4.1]
# Starting with a directory with only the script in it:
mike@ebx2009:~/test$ ls
version_check.py
# I use the "-C ." to force the ".cover" files to be dumped in my current directory:
mike@ebx2009:~/test$ python -m trace --count -C . version_check.py
2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
[GCC 4.4.1]
mike@ebx2009:~/test$ ls
threading.cover version_check.cover version_check.py
# So this worked fine.
# Let's remove the cover files and try with Python 3.1:
mike@ebx2009:~/test$ rm *.cover
mike@ebx2009:~/test$ ls
version_check.py
mike@ebx2009:~/test$ python3 -m trace --count -C . version_check.py
3.1.1 (r311:74480, Feb 7 2010, 16:32:28)
[GCC 4.4.1]
mike@ebx2009:~/test$ ls
threading.cover version_check.py
# Its annoying that the threading.cover is still being made, but "version_check.cover" did not get generated in any case...
I tracked the problem down inside of lib/trace.py (same code in both python versions):
def localtrace_count(self, frame, why, arg):
if why == "line":
filename = frame.f_code.co_filename
print(frame.f_code.co_filename) # my new debug line
lineno = frame.f_lineno
key = filename, lineno
self.counts[key] = self.counts.get(key, 0) + 1
return self.localtrace
If you put my print debug line in, we get some more interesting behavior from my example runs:
mike@ebx2009:~/test$ python -m trace --count -C . version_check.py
/usr/lib/python2.6/threading.py
<string>
version_check.py
version_check.py
version_check.py
version_check.py
version_check.py
version_check.py
2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
[GCC 4.4.1]
mike@ebx2009:~/test$ python3 -m trace --count -C . version_check.py
/usr/local/lib/python3.1/threading.py
<string>
<string>
<string>
<string>
<string>
<string>
<string>
3.1.1 (r311:74480, Feb 7 2010, 16:32:28)
[GCC 4.4.1]
So python3 is not retaining the module name correctly. Instead its just giving "<string>". So the bottom line is "frame.f_code.co_filename" is now behaving differently. I'm not sure how to fix that. |
|
Date |
User |
Action |
Args |
2010-02-21 20:12:26 | mnewman | set | recipients:
+ mnewman, mark |
2010-02-21 20:12:26 | mnewman | set | messageid: <1266783146.03.0.945566392413.issue6436@psf.upfronthosting.co.za> |
2010-02-21 20:12:24 | mnewman | link | issue6436 messages |
2010-02-21 20:12:23 | mnewman | create | |
|