|
From: SourceForge.net <no...@so...> - 2011-02-28 04:11:58
|
Patches item #3194663, was opened at 2011-02-27 23:11 Message generated for change (Tracker Item Submitted) made by rvolpe-swn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3194663&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: rv...@se... (rvolpe-swn) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent LoadPythonServiceClass from importing non-services Initial Comment: The current implementation of LoadPythonServiceClass appends the target module's directory to sys.path. This means that if the target module's name is shadowed by that of another module already on sys.path, that shadowing module will be imported instead, leading to a cryptic "Python could not find the service class in the module" error logged to the Application event log. As an example, attempting to load the module "C:\Python27\lib\site-packages\pywinservice_example\test.py" loads the module "C:\Python27\lib\test\__init__.pyc" instead. This patch changes the logic to insert the module's directory at the beginning of sys.path, then remove it after attempting to import the module. The upside is that formerly shadowed module names (like "test.py") are now usable as service module names. The downside is that if the service module attempts to import another module with the same name, the service module itself will be imported instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3194663&group_id=78018 |
