Attached zip archive can be run directly to reproduce the bug:

$ ./python.exe bug.zip 
Traceback (most recent call last):
  File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 162, in 
_run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Users/sasha/Work/python-svn/trunk/Lib/runpy.py", line 72, in 
_run_code
    exec code in run_globals
  File "bug.zip/__main__.py", line 9, in <module>
  File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 268, in 
strip_dirs
    (cc, nc, tt, ct, newcallers))
  File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 516, in 
add_func_stats
    add_callers(t_callers, callers))
  File "/Users/sasha/Work/python-svn/trunk/Lib/pstats.py", line 526, in 
add_callers
    zip(caller, new_callers[func])])
TypeError: zip argument #1 must support iteration


This is a regression introduced by r60149 which fixed processing of 
cProfile data, but broke processing of profile.

It is fairly easy to fix this problem in pstats, but a better solution 
may be to make profile output compatible with cProfile.

See also issue1269 and issue1315 .

I am attaching a simple fix.  The test for data format could be taken out 
of the loop, but it is probably not worth complicating the logic.  In any 
case the real issue is whether profile and cProfile should produce 
compatible output or not.

Alexander, how hard would it be to change the profile output?

It would be fairly easy to change format before dumping stats to disk,
but unfortunately Profile does not encapsulate it's run-time data and
changing its format would be a mess.

Of course, one can hack around that by turning Profile.stats into a
computed property, but that's hardly an acceptable solution.

I think it is worthwhile fixing the on-disk format, but as a long-tem
solution one may consider adding common (possibly iterator-based) API
to both profile and cProfile that pstats can use instead of accessing
internal data structures.

Creating an ABC for a standard Python profiler, seems to be a
worthwhile project that in the future may simplify plugging in 3rd
party profilers, but I don't have expertise to undertake such a
project.  That would require experience with multiple Python profilers
that I don't have.

On Mon, Nov 23, 2009 at 3:31 PM, Georg Brandl <report@bugs.python.org> wrote:
>
> Georg Brandl <georg@python.org> added the comment:
>
> Alexander, how hard would it be to change the profile output?
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue7372>
> _______________________________________
>

See also #7372.

AFAIU add_callers can receive either a tuple or an int (and this is what is not working now). When I looked at #7372 I wasn't able to find out why it might receive two different objects and not always the same (i.e. always a tuple, possibly with only one int). From the first message it seems that cProfile returns the tuple of 4 ints and profile returns a single int.
Can profile be fixed to return a tuple (of 4 or 1 ints) too?

I meant "See also #6710".

On Mon, Jan 25, 2010 at 7:35 PM, Ezio Melotti <report@bugs.python.org> wrote:
>
> Ezio Melotti <ezio.melotti@gmail.com> added the comment:
>
> See also #7372.
>
> AFAIU add_callers can receive either a tuple or an int (and this is what is not working now). When I looked at #7372 I wasn't able to find out why it might receive two different objects and not always the same (i.e. always a tuple, possibly with only one int). From the first message it seems that cProfile returns the tuple of 4 ints and profile returns a single int.
> Can profile be fixed to return a tuple (of 4 or 1 ints) too?

Ah interesting.  I ran into this recently when I noticed that some
analysis tools I'd written a while back no longer worked and had to be
updated because data that were ints were now tuples.

Aside from these particular issues, it would be really great if the
profiler stats data structure was specified. :)

Jim

Fixed with your patch in r83531.

I just ran into this problem with pstats under Python 2.7.  The ticket is marked as "fixed", but it looks like the change was only checked in under the py3k branch.

What's the policy on fixing stuff like this for 2.7 patch releases?

Thanks,
Doug

This change was backported to the 2.7 branch in r83533; it should therefore be in 2.7.1, but not 2.7.