This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: trace module doesn't seem to produce .cover files for Py3 (but does for Py2)
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.0, Python 3.1, Python 3.2
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: georg.brandl, mark, mnewman
Priority: normal Keywords:

Created on 2009-07-08 06:37 by mark, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit mnewman, 2010-02-21 20:12 python version checking script
Messages (3)
msg90252 - (view) Author: Mark Summerfield (mark) * Date: 2009-07-08 06:37
When I execute the following command line (Linux, Fedora 10) using
Python 2.5 or 2.6, I get a .cover file:

python2.5 -m trace --count

But when I do this with Python 3.0 or 3.1, no .cover file is output.

I didn't notice anything in the documentation suggesting a change in
behaviour, but I'm not familiar with this module, so perhaps I've missed
msg99679 - (view) Author: Michael Newman (mnewman) Date: 2010-02-21 20:12
I noticed the same behavior today.

Let's consider a test case using my python script "" (attached).

Normally the script does the following on my Ubuntu 9.10 box:

# Python 2.6 example:
mike@ebx2009:~/test$ which python
mike@ebx2009:~/test$ python
2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1]

# Python 3.1 example:
mike@ebx2009:~/test$ which python3
mike@ebx2009:~/test$ python3
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
# I use the "-C ." to force the ".cover" files to be dumped in my current directory:
mike@ebx2009:~/test$ python -m trace --count -C . 
2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1]
mike@ebx2009:~/test$ ls
threading.cover  version_check.cover
# 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
mike@ebx2009:~/test$ python3 -m trace --count -C . 
3.1.1 (r311:74480, Feb  7 2010, 16:32:28) 
[GCC 4.4.1]
mike@ebx2009:~/test$ ls
# 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/ (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 . 
2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1]

mike@ebx2009:~/test$ python3 -m trace --count -C . 
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.
msg112455 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-08-02 12:35
Duplicate of #1690103.
Date User Action Args
2022-04-11 14:56:50adminsetgithub: 50685
2010-08-02 12:35:47georg.brandlsetstatus: open -> closed

nosy: + georg.brandl
messages: + msg112455

resolution: duplicate
2010-02-21 20:12:24mnewmansetfiles: +
versions: + Python 3.2
nosy: + mnewman

messages: + msg99679
2009-07-08 06:37:36markcreate