import headaches/gripes

[Costas Menico]

Paul Prescod <paulp at ActiveState.com> wrote:

>> Why can't the import statement be smart enough to check if a file was
>> changed to import it anyway? All it has to do is compare .py to the
>> last import date/time.
>
>I think there are two reasons:
>
> 1. Even checking file dates has a performance cost. It involves going
>to the hard disk after all. Code like this isn't rare in Python
>
>def foo():
>   import bar
>   ....
>
> 2. What would happen if you built a big, long-running application and
>then changed a file while it was running. Would you really want one
>import statement in the file to load the new version? Then you would
>have objects floating around from the old version alongside objects from
>the new version. When it crashed due to the inconsistency, it would be
>very confusing.
>
>Pythonwin is one big long-running Python app. In that particular
>situation you might prefer it to act differently but Python doesn't
>really have a feature that allows what you want...and even if it did,
>you'd have to be careful because you could get into the same situation
>where you had old objects hanging around with the old behavior. That
>happens even with a reload today.
>
>> if module_exists(utils):
>>         reload(utils)
>> else:
>>         import utils
>
>You can make it simpler than that:
>
>import utils
>reload(utils)
>
>The first operation will continue silently and quickly if the module is
>loaded. Then it will be reloaded. The only "cost" is that the very first
>time you would load the module twice in a row...

Well, I didnt expect anyone to change the way the import works. But
your idea of the two in a row is good. Now if I could write a function
that I can call to do this, then I can enable and disable the reload()
at will.

Maybe a solution:

import aModule1 alias aName1; assert reload(aName1)
import aModule2 alias aName2; assert reload(aName2)

Then turn off debugging when done.

Thanks

Costas