[ python-Bugs-716587 ] profile.run makes assumption regarding namespace

[SourceForge.net]

Bugs item #716587, was opened at 2003-04-07 06:56
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 1
Submitted By: Greg Fortune (gregfortune)
>Assigned to: Neil Schemenauer (nascheme)
Summary: profile.run makes assumption regarding namespace

Initial Comment:
When profile.run() is executed, it assumes that the local 
and global namespace should be determined from the 
locals and globals for __main__.  In the case of an 
embedded interpreter, this is an annoying assumption.

For instance, I have a PyQt program that has an 
embedded interpreter running as a "debug" console and 
need to profile a little segement of misbehaving code.  
With direct access to all the gui interactively, it seemed 
like a simple task of profiling a function call on one of my 
gui elements, but the namespace in the interpreter is very 
different from that of the main application.

A simple fix is to allow profile.run to be executed with an 
optional dict so the user can give their own namespace.  
A diff -u is attached which accomplishes this.

Note that this problem appears in the current Python CVS 
on sourceforge, but exists at least as early as Python 2.2.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-21 13:41

Message:
Logged In: YES 
user_id=35752

I always use 'run_call'.  You can easily make a closure to
capture any bindings you want.  Usually it is not necessary.

run_call should be available as a global function and it
should be documented, IMHO.

----------------------------------------------------------------------

Comment By: Greg Fortune (gregfortune)
Date: 2004-03-20 23:40

Message:
Logged In: YES 
user_id=155459

Partially because the only entry point to the profiler mentioned in the 
documentation is profile.run.  If the Profile class were documented, it 
would be a little more obvious how one would work around the 
limitation. 
 
Secondly, the assumption that __main__ is always the desired 
namespace seems limiting and arbitrary.  Anybody wanting to profile 
inside an embedded interpreter is going to have to dig through the 
code the same way I did to identify the problem. 
 
Could the namespace be magically determined based on the function 
that is being profiled?  If so, that is probably an even better solution as 
it becomes a none issue.  At the very least, profile.run should grab the 
namespace from the current interpreter rather than __main__ and 
that's probably better than my initial proposal anyway. 
 
So, it's not a matter of being impossible to work around...  It's just not 
an ideal interface yet. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 23:01

Message:
Logged In: YES 
user_id=6380

I don't see the issue. Why can't you use

  prof = profile.Profile()
  prof.runctx(cmd, mydict, mydict)

???


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 06:18

Message:
Logged In: YES 
user_id=80475

This seems like a reasonable request.  The use case is 
uncommon but I don't like having __main__ hardwired in 
the code.  What do you think?

If you want the change, should it be put into Py2.3?

----------------------------------------------------------------------

Comment By: Greg Fortune (gregfortune)
Date: 2003-04-07 14:36

Message:
Logged In: YES 
user_id=155459

Doh, sorry about that.  Guess I should actually check it after I 
submit...


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-07 12:31

Message:
Logged In: YES 
user_id=6656

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470