rocky wrote:
Someone recently reported a problem in pydb where a function defined
in his program was conflicting with a module name that pydb uses. I
think I understand what's wrong, but I don't have any elegant
solutions to the problem. Suggestions would be appreciated.
In a nutshell, here's the problem:
In file fns:
def foo(): print "foo"
In file pdebug.py:
import fns, sys
def trace_dispatch(frame, event, arg):
fns.foo()
print frame, event, arg
return trace_dispatch
sys.settrace(trace_dispatch)
execfile('myprogram.py')
Finally file myprogram.py:
def fns(): print "This is the *other* fns"
When you run pdebug.py you get:
$ python pdebug.py
foo
<frame object at 0xdd9030> call None
foo
<frame object at 0xdd9030> line None
Traceback (most recent call last):
File "pdebug.py", line 7, in <module>
execfile('myprogram.py')
File "myprogram.py", line 1, in <module>
def fns(): print "This is the *other* fns"
File "pdebug.py", line 3, in trace_dispatch
fns.foo()
AttributeError: 'function' object has no attribute 'foo'
Basically inside the trace hook, local functions are visible and take
precedence over (global) module names. I could move "import fns"
inside trace_dispatch(), but I'd have to do that in all of the methods
that module "fns" is used. Also note that using the form:
from fns import foo
would eliminate the conflict on "fns", but I'd still have potential
conflicts on "foo". Using more obscure names (e.g. pydb_fns) would
reduce the chance of a conflict but not eliminate it.
Suggestions?
Some context would be useful. For example, you may be writing pdebug.py
as a library to be used by other developers, and you want to minimize
the likelihood that arbitrary code they write will conflict. If you own
all the code, I'd just say to rename one or the other.
My preference is also for using import of myprogram, as I've never
needed execfile(). But if you need one of the features of execfile(),
and really want myprogram in the same namespace, then you probably ought
to obfuscate the other import.
Instead of import fns, try:
import fns as _module_fns
And of course any references to the module will use the longer name.
The leading underscore is a clue that the name is not to be used outside
of the module. And the prefix 'module' helps to make it unlikely
they'll make a data or function or class with that name.
--
http://mail.python.org/mailman/listinfo/python-list
