<p dir="ltr"><br>
On 12 Feb 2013 07:56, "Alessandro Dentella" <<a href="mailto:sandro@e-den.it">sandro@e-den.it</a>> wrote:<br>
><br>
> On Mon, Feb 11, 2013 at 04:11:38PM -0500, PJ Eby wrote:<br>
> > On Mon, Feb 11, 2013 at 11:40 AM, Alessandro Dentella <<a href="mailto:sandro@e-den.it">sandro@e-den.it</a>> wrote:<br>
> > ><br>
> > > I believe that this issue belongs to this list, please let me know if I'm<br>
> > > wrong.<br>
> > ><br>
> > > Suppose I have 2 packages:<br>
> > ><br>
> > >   jmb.foo<br>
> > >   jmb.bar<br>
> > ><br>
> > > distributed separately. Each has in jmb's __init__ a standard:<br>
> > ><br>
> > ><br>
> > >   __import__('pkg_resources').declare_namespace(__name__)<br>
> > ><br>
> > > or<br>
> > ><br>
> > >   from pkgutil import extend_path<br>
> > >   __path__ = extend_path(__path__, __name__)<br>
> > ><br>
> > ><br>
> > > I just realized that imp.find_module() will return "fake" values<br>
> > ><br>
> > >   imp.find_module('jmb', None)<br>
> > ><br>
> > > may return (a tuple with) the path from the first package or from the<br>
> > > second. Many framework will fail to discover commands in the inner module:<br>
> > > one is detailed here [1] another is Django way of getting application's<br>
> > > commands.<br>
> > ><br>
> > > I find it misleading to return a value that is not thorohly correct.<br>
> > ><br>
> > > Is there a workaround? Is the current behaviour considered correct for<br>
> > > reasons I don't yet understand?<br>
> ><br>
> > Since Python 2.5, the right way to do this is with<br>
> > pkgutil.iter_modules() (for a flat list) or pkgutil.walk_packages()<br>
> > (for a subpackage tree).<br>
> ><br>
> > For your example, if I wanted to find just the subpackages of 'jmb', I would do:<br>
> ><br>
> >     import jmb, pkgutil<br>
> >     for (module_loader, name, ispkg) in<br>
> > pkgutil.iter_modules(jmb.__path__, 'jmb.'):<br>
> >         # 'name' will be 'jmb.foo', 'jmb.bar', etc.<br>
> >         # 'ispkg' will be true if 'jmb.foo' is a package, false if it's a module<br>
><br>
> thanks for the answer but this way I need to really import jmb while<br>
> imp.find_module doesn't really import it. I *think* that django people<br>
> wanted to test if some modules are present w/o importing. If an import<br>
> occurs, since I already know the name it should have, it bettere to try that<br>
> one directly.</p>
<p dir="ltr">In that case, not without upgrading to Python 3.3 and using the native namespace package support. In earlier versions you *have* to import the parent packages in order to run the code that populates the full path for the namespace packages.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
><br>
> sandro<br>
> *:-)<br>
><br>
> --<br>
> Sandro Dentella  *:-)<br>
> <a href="http://www.reteisi.org">http://www.reteisi.org</a>             Soluzioni libere per le scuole<br>
> <a href="http://sqlkit.argolinux.org">http://sqlkit.argolinux.org</a>        SQLkit home page - PyGTK/python/sqlalchemy<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Catalog-SIG mailing list<br>
> <a href="mailto:Catalog-SIG@python.org">Catalog-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/catalog-sig">http://mail.python.org/mailman/listinfo/catalog-sig</a><br>
</p>