[Tutor] getattr works sometimes

Tino Dai oberoc at gmail.com
Fri Oct 5 16:02:31 CEST 2012

On Tue, Oct 2, 2012 at 8:39 PM, Steven D'Aprano <steve at pearwood.info> wrote:

> On 03/10/12 04:20, Tino Dai wrote:
>> and the get_class class works sometime for finding modules within a
>>>> certain directory. If the get_class
>>>> doesn't work, it throws an AttributeError.
>>> I don't really understand what you mean by this. Can you copy and
>>> paste the actual error message (all of it)?
>>>> The module exists in the directory, and I'm trying to debug this. Does
>>>> anybody have any hints to go about debug
>>>> this?
>> get_class('etl.transfers.bill_**subject')      #
>> etl.transfers.bill_subject does exist under the transfers directory
>> <module 'etl.transfers.bill_subject' from
>> './leg_apps/etl/transfers/**bill_subject.pyc'>
> I don't understand why you are using the get_class function for this.
> It is only useful when you don't know the name of the object until
> runtime. Since you know the name, I would suggest that using a regular
> import is better:
> from etl.transfers import bill_subject
> Imports also work differently to getattr, and I believe that is where
> you are running into trouble. The (wrongly named) get_class function
> uses getattr to extract names from a single top-level module. But that's
> not what you are trying to do: you are trying to extract modules from
> a package.

Where I was running into problems was the fact that I needed to import the
modules before I could do a getattr using the get_class function. In
retrospect, I'm bringing in basically all the objects anyway, so there
really is no need to have this complicated set up.

> Use the right tool for the job: you are trying to use a screwdriver when
> you need a screwdriver.
> My prediction is that *at some point* in your experiments, you have done
> something like:
> etl.transfers.bill_subject = bill_subject
> *or something with the same effect*. Perhaps the "transfers" module
> includes one of these lines:
> import bill_subject  # Python 2.5 or older?
> from . import bill_subject
> Now bill_subject is an attribute of the transfers module, and getattr can
> see it. But you haven't done the same for related_bills, and so getattr
> cannot see it.
> Instead, use the right tool, import, which is designed for solving your
> problem:
> from etl.transfers import bill_subject
> from etl.transfers import related_bills
> should both work, unless you have removed the bill_subject.py and
> related_bills.py files from the etl/transfers/ directory.
> Actually Steve, I don't know the correct classes to import until runtime.
This is part of a bigger ETL (Extract - Transform - Load) routine, and this
is the section that deals with records that didn't make it over because of
some missing constraint. You are probably right in the fact that I just
should import all the classes in and be done with it.

But that brings me to my next question, how do I prevent from polluting the
namespace with unneeded imports. Is there a way to de-import modules? Is
there an idiom that pertains to this?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20121005/aa3c8818/attachment.html>

More information about the Tutor mailing list