openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #00268
Re: Lazy import of modules
At the risk of starting to shave yaks: do we want to have an openstack-common then? It seems to be DOA at the moment.
Ewan.
> -----Original Message-----
> From: Todd Willey [mailto:todd@xxxxxxxxxxxx]
> Sent: 12 January 2011 15:03
> To: Ewan Mellor
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Lazy import of modules
>
> I ported an import behavior to openstack-common's pluggable.py, and
> there is some blueprint information at
> http://wiki.openstack.org/blueprint-flagged-module-loading.
>
> It doesn't raise it's own error, it just uses __import__, so it should
> fix the problem you were seeing. I'm open to backporting it or to
> actually start using openstack-common.
>
> -todd[1]
>
> On Wed, Jan 12, 2011 at 5:48 PM, Ewan Mellor
> <Ewan.Mellor@xxxxxxxxxxxxx> wrote:
> > I've heard people complain that we have lots of ways of doing lazy
> import of
> > modules (i.e. loading them on demand, so that you don't need the
> dependency
> > unless you're actually using the functionality) and that we should
> > standardize on one.
> >
> >
> >
> > So, which one should we standardize on?
> >
> >
> >
> > To kick the conversation off, I don't like the way that
> > nova.utils.{import_object,import_class} work today, having recently
> chased
> > down a problem that was completely hidden by them. I had an object A
> that
> > was lazy-loaded using import_object, and A in turn imported B, which
> was
> > missing. import_object caught the ImportError for B, decided that it
> meant
> > that A wasn't present, attempted to import it using import_class, and
> that
> > failed too, and then it eventually got logged as 'Class A cannot be
> found'.
> > This was wrong firstly because A was not missing, and secondly
> because A
> > wasn't a class, and thirdly because the code didn't ask to import it
> as a
> > class! There was no indication that B was missing.
> >
> >
> >
> > This took me a long time to unpick, so if we're going to standardize
> around
> > nova.utils.import_x, then we need to figure out a better way for them
> to
> > work.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Ewan.
> >
> >
> >
> > def import_class(import_str):
> >
> > """Returns a class from a string including module and class"""
> >
> > mod_str, _sep, class_str = import_str.rpartition('.')
> >
> > try:
> >
> > __import__(mod_str)
> >
> > return getattr(sys.modules[mod_str], class_str)
> >
> > except (ImportError, ValueError, AttributeError), exc:
> >
> > logging.debug(_('Inner Exception: %s'), exc)
> >
> > raise exception.NotFound(_('Class %s cannot be found') %
> class_str)
> >
> >
> >
> > def import_object(import_str):
> >
> > """Returns an object including a module or module and class"""
> >
> > try:
> >
> > __import__(import_str)
> >
> > return sys.modules[import_str]
> >
> > except ImportError:
> >
> > cls = import_class(import_str)
> >
> > return cls()
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
> >
>
>
>
> --
> CONFIDENTIALITY NOTICE: This email is for sole use of intended
> recipient(s). Unauthorized use is prohibited.
Follow ups
References