On 12 Feb 2013 07:56, "Alessandro Dentella" <san...@e-den.it> wrote:
>
> On Mon, Feb 11, 2013 at 04:11:38PM -0500, PJ Eby wrote:
> > On Mon, Feb 11, 2013 at 11:40 AM, Alessandro Dentella <san...@e-den.it>
wrote:
> > >
> > > I believe that this issue belongs to this list, please let me know if
I'm
> > > wrong.
> > >
> > > Suppose I have 2 packages:
> > >
> > > jmb.foo
> > > jmb.bar
> > >
> > > distributed separately. Each has in jmb's __init__ a standard:
> > >
> > >
> > > __import__('pkg_resources').declare_namespace(__name__)
> > >
> > > or
> > >
> > > from pkgutil import extend_path
> > > __path__ = extend_path(__path__, __name__)
> > >
> > >
> > > I just realized that imp.find_module() will return "fake" values
> > >
> > > imp.find_module('jmb', None)
> > >
> > > may return (a tuple with) the path from the first package or from the
> > > second. Many framework will fail to discover commands in the inner
module:
> > > one is detailed here [1] another is Django way of getting
application's
> > > commands.
> > >
> > > I find it misleading to return a value that is not thorohly correct.
> > >
> > > Is there a workaround? Is the current behaviour considered correct for
> > > reasons I don't yet understand?
> >
> > Since Python 2.5, the right way to do this is with
> > pkgutil.iter_modules() (for a flat list) or pkgutil.walk_packages()
> > (for a subpackage tree).
> >
> > For your example, if I wanted to find just the subpackages of 'jmb', I
would do:
> >
> > import jmb, pkgutil
> > for (module_loader, name, ispkg) in
> > pkgutil.iter_modules(jmb.__path__, 'jmb.'):
> > # 'name' will be 'jmb.foo', 'jmb.bar', etc.
> > # 'ispkg' will be true if 'jmb.foo' is a package, false if it's
a module
>
> thanks for the answer but this way I need to really import jmb while
> imp.find_module doesn't really import it. I *think* that django people
> wanted to test if some modules are present w/o importing. If an import
> occurs, since I already know the name it should have, it bettere to try
that
> one directly.
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.
Cheers,
Nick.
>
>
> sandro
> *:-)
>
> --
> Sandro Dentella *:-)
> http://www.reteisi.org Soluzioni libere per le scuole
> http://sqlkit.argolinux.org SQLkit home page -
PyGTK/python/sqlalchemy
>
>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG@python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
