Bugs item #716587, was opened at 2003-04-07 00:56 Message generated for change (Comment added) made by gregfortune 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: Guido van Rossum (gvanrossum) 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.

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

Date: 2004-03-20 16: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 16: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 00: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 08: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 06: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. :-( )

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