Hi Peter. Thank you for this warning. I'll document this in the code. I plan on importing only from dependentpackage for portability. Also, much in the framework relies upon it. This approach is primarily for maintenance purposes and would also allow me to package the modified dependentpackage (with just the __init__.py ) along with mypackage if I plan to distribute it. It allows it to be a drop in replacement.
I am hoping with packaging utilities, I can easily remove the dependentpackage if it is encountered in site-packages to replace it with my own. Regards, David Peter Otten wrote: > Peter Otten wrote: > >>> I'd appreciate hearing of what I can do in an __init__ file or what >>> other strategy could make this work. Many thanks. >> I think fixing the imports is the better long-term approach. But putting >> >> from pkgutil import extend_path >> import mypackage >> __path__ = extend_path(mypackage.__path__, __name__) >> >> into dependentpackage/__init__.py might work. > > One big caveat: If you are mixing both > > import mypackage.somemodule > > and > > import dependentpackage.somemodule > > in the same application, mypackage.somemodule and > dependentpackage.somemodule are *not* the same module instance. This may > have surprising effects when global variables in somemodule.py are > updated... > > Peter -- http://mail.python.org/mailman/listinfo/python-list
