From: Steven D'Aprano on
On Wed, 23 Dec 2009 15:18:10 -0800, Carl Banks wrote:

>> > # will unload mod1 assuming mod1 was the only reference to that
>> > module.
>>
>> Which is highly unlikely. Any classes or functions from the module will
>> keep the module alive.
>
> Actually, they won't. Neither classes nor functions directly reference
> their module; classes know their module only by name, and functions only
> hold references to the module's namespace, not to the module itself. So
> if any references to functions defined in the module remain, the module
> dict will stick around, but the module itself may be collected.

Hmmm... so it seems. Well spotted, thanks.

It makes sense to do it that way, as it prevents circular references
(module contains a class which contains the module which...).



--
Steven
From: Steve Holden on
lordofcode wrote:
> Hi All
>
> Not an expert in Python, so sorry if this sounds like a silly
> question.
> I went through other few threads in the mailing list but they are not
> helping me much.
> I have run into a problem related to dynamically loading and unloading
> a module.
> I need to dynamically load a module and unload it and load another
> module.
>
> For example I have many files(All files in Python are modules right?)
> like mobile_1.py ,mobile_2.py, mobile_3.py etc.. in my project folder
> which contains classes and methods with same name but different
> functionality.(am afraid I cannot change this structure as these files
> are generated randomly by the user)
>
> So initially when my program starts I have to load a default module. I
> do this as follows:
> ##############################
>>> MODULE_name = "mobile_1"
>>> exec "from "+MODULE_name+" import *"
> ##############################
> And use the methods defined in "mobile_1.py" file
>
> Now as the application continues , I may have to use the methods
> defined in "mobile_2.py" or "mobile_3.py" etc instead of the
> previously loaded module,which I incorrectly try to do as below:
> ####################
>>> MODULE_name = "mobile_2"
>>> exec "from "+MODULE_name+" import *"
> #####################
> The above import does not have any impact and the methods called from
> my application still pertain to mobile_1.py as its still in the
> current namespace(?).
> I tried below code with del(), reload() etc but could not figure it
> out.
> ###Code to unload a dll####
>>> del sys.modules[MODULE_name] #==> does not delete the reference in namespace
>
>
> 1)How do I unload a module dynamically and completely remove the
> references in the module so a new module with same name references can
> be loaded?
> 2)Are there any alternative way to do the above requirement?
> Currently I am working around by restarting the whole initial setup
> for each new module which is unnecessary waste.Can I avoid this
> "reset"?
>
I'd argue that you don't want to unload the old code before loading the
new module, and that what you really need is an understanding that if
mod1 and mod2 both define a function called f then you can perfectly
happily reference the two functions as

mod1.f

and

mod2.f

Indeed, if x is some object that needs processing by functions f, g and
h from module mod1 then it's perfectly valid to write

mod = mod1
result = mod.f(mod.g(mod.h(x)))

for example. So you can write code that uses the appropriate module for
each input.

It's possible, of course, that I am misunderstanding your requirements,
but I hope that helps.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

From: Jean-Michel Pichavant on
Steven D'Aprano wrote:
> On Wed, 23 Dec 2009 15:31:53 +0100, Jean-Michel Pichavant wrote:
>
>
>> Steven D'Aprano wrote:
>>
>>> On Wed, 23 Dec 2009 13:37:06 +0100, Jean-Michel Pichavant wrote:
>>>
>>>
>>>
>>>> But believe me, you don't want to mess up with the python import
>>>> mechanism.
>>>>
>>>>
>>>>
>>> Unless you understand how it works.
>>>
>>>
>>>
>>>
>> Let me quote the OP: 'Not an expert in Python' I was just answering the
>> OP question, without refering to something he could do if he was someone
>> else.
>>
>
> But what he *can* do is to learn how importing works. I'm not sure it's
> terribly helpful to tell somebody all the things they can't do instead of
> what they can.
>
>
>
Hacking python imports would not be in the top of the list of things I
would teach to some python newcomer, that was my point.

And to be a little more constructive, let's give the OP a litle bit of help.

How can you unload module in python ?

That I don't know, anyone knows ?

JM
From: Lie Ryan on
On 12/24/2009 11:51 PM, Jean-Michel Pichavant wrote:
>> But what he *can* do is to learn how importing works. I'm not sure
>> it's terribly helpful to tell somebody all the things they can't do
>> instead of what they can.
>>
>>
> Hacking python imports would not be in the top of the list of things I
> would teach to some python newcomer, that was my point.
>
> And to be a little more constructive, let's give the OP a litle bit of
> help.
>
> How can you unload module in python ?
>
> That I don't know, anyone knows ?

Given that there is no way to ensure deconstruction of an object
instance (`del` only removes the reference and __del__ can only remove
the resources used by the instance but not the instance itself), why
would anyone expect it is possible to unload a module explicitly (which
is a deconstruction of the module)
From: Aahz on
In article <78388a7a-b148-499a-8894-34e55721eda3(a)k19g2000pro.googlegroups.com>,
lordofcode <ajay.bgr(a)gmail.com> wrote:
>
>Thanks you all for your replies ,cleared quiet a few doubts about
>importing modules and namespace references .
>Currently am going with static importing of all modules. But it may
>not be efficient in future as the number of interchangeable modules
>that I have to import may run in 30-40's.(Basically this Python code
>is part of larger GSM Testing project where each module represents one
>model of GSM mobile phone and this number keeps growing). So changing
>the design will be a last resort.

Worry when you have 30-40 hundreds of modules. ;-) Seriously, it's just
memory; Python's efficient dicts make lots of modules not a problem.

If/when it's time to worry, there are other techniques you can use.
--
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair