Importing a class without knowing the module

[Mike Meyer]

aleax at mail.comcast.net (Alex Martelli) writes:
> Mike Meyer <mwm at mired.org> wrote:
>    ...
>> > How do you arrange a module so that its classes' __module__ attributes
>> > don't tell you the name of the module "that would be useful", yet the
>> > module's __file__ DOES give you information that you can usefully
>> > process, heuristically I assume, to infer a module name that IS useful?
>> So what module name do you import if C.__module__ is __main__?
> In this case, I would strongly suggest that raising an exception upon
> the attempt to marshal is better than trying to guess that the file
> holding the main script could later be innocuously imported from a
> different script, or, alternatively, that the same main script would be
> running when a future unmarshaling attempt is done.  "In the face of
> ambiguity, refuse the temptation to guess" is a sound principle.

Once you move the data to another system, pretty much anything you do
to try and figure out how to load the code that defines a class is
ambiguous. After all, it may not be present at all. The only way to
avoid ambiguity is to serialize the code.

>> > I just don't see it, which of course doesn't mean it can't be done, with
>> > sufficient evil ingenuity.  But since you're the one arguing that this
>> > case is important enough to be worth dwelling on,
>> I'm not dwelling on it, you are.  All I did was recommend using the
>> module name if you had one, and if not then the file name was your
>> best bet. You chose to ignore part of my statement to focus on the
>> part you disagreed with, because you thought what I had suggested in
>> the first place was a better idea. I pointed out this oversight on
>> your part, and you've been dwelling on it ever since.
> I don't see the history of this thread the same way as you do,
> apparently.

Given that this is netnews, that's not at *all* surprising.

> i.e., your post, to which I was replying, was about 3 hours later than
> my original one.  My original post said:

Ok, so you suggested it first. Congratulations. I didn't see them in
that order. I didn't reply to that post of yours. I replied to the OP
pointing out that the problem with __file__ being system-dependent. He
never suggested using module.

> so it seems incorrect to say that you had "suggested in the first place"
> the idea of using __module__; on the contrary, in a previous post of
> yours, the first one of yours on this thread, specifically:
>> How about adding Foo.__file__ to the serialized data?
> So, it seems to me that you're the one dwelling on the issue, because
> you made the original wrong suggestion, and after I corrected it,
> repeated and are now defending the gist of it (though not the obviously
> wrong idea of using a non-existent __file__ attribute of the Foo class).

I never did anything to defend it. As soon as the OP pointed out that
he'd didn't like __file__ because of the loss of system independence,
I suggested using the module, and mentioned that he might not have a
better choice than to use __file__ anyway. You overlooked the mention
of __module__ to complain that __file__ wasn't his best choice,
because he could use __module__. All I did was point out what you
overlooked, and have been answering your questions about it ever
since. If you don't think __file__ is such a good idea, you should
have said so in the first place. Instead, you asked questions about
it. Trying to help you out, I answered them. If trying to help someone
who seems to be having trouble understanding an issue is "dwelling on
the issue", well, I'm glad we have a newsgroup full of people who
dwell on issues.

      <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.