Michael Newman <michael.b.new...@gmail.com> added the comment:

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:
m...@ebx2009:~/test$ which python
/usr/bin/python
m...@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:
m...@ebx2009:~/test$ which python3
/usr/local/bin/python3
m...@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:
m...@ebx2009:~/test$ ls
version_check.py
# I use the "-C ." to force the ".cover" files to be dumped in my current 
directory:
m...@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]
m...@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:
m...@ebx2009:~/test$ rm *.cover
m...@ebx2009:~/test$ ls
version_check.py
m...@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]
m...@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:

m...@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]

m...@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.

----------
nosy: +mnewman
versions: +Python 3.2
Added file: http://bugs.python.org/file16282/version_check.py

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue6436>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to