This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author htrd
Recipients
Date 2002-11-25.08:21:37
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=46460

Changing this behaviour would make it difficult to write frozen programs 
whose behaviour is predictable - where the behaviour can not be subverted 
by files with funny names. This is important for: 
1. suid frozen programs (although there are other ways around this) 
2. vendors who ship frozen programs, who dont want it to break if the 
user happens to have a funny named file in the current directory (yes, this 
really happened.) 
 
It is currently possible to work around this new problem in pure python, by 
importing the extension module packagelessly, and twiddling sys.modules to 
add it to the package. I think this solution is well known in the python/COM 
world, where there are many extension modules in the win32com package. 
The following example hack is taken from the top of one of our frozen 
products: 
 
if pythoncom.frozen: 
    # A bug in freeze causes problems for extension modules that originally 
appeared in packages. 
    # They can only be imported packagelessly. 
    def _fix_frozen_extensions(package_name,extension_name): 
        extension = sys.modules[package_name+'.'+extension_name] = 
__import__(extension_name) 
        __import__(package_name) 
        setattr(sys.modules[package_name],extension_name,extension) 
    _fix_frozen_extensions('GeminiDataLoggers.Cedar','SimplePort') 
    _fix_frozen_extensions('GeminiDataLoggers.Cedar','SimpleMAPI') 
    _fix_frozen_extensions('GeminiDataLoggers.Cedar','WinINet') 
    _fix_frozen_extensions('win32com.axcontrol','axcontrol') 
 
    
Is there a reason why the extension needs to be dynamically loaded, rather       
History
Date User Action Args
2007-08-23 15:04:48adminlinkissue416704 messages
2007-08-23 15:04:48admincreate