> release. The main reason why I changed the import behavior was > pythonservice.exe from the win32 extensions. pythonservice.exe imports > the module that contains the service class, but because > pythonservice.exe doesn't run in optimized mode, it will only import a > .py or a .pyc file, not a .pyo file. Because we always generate bytecode > with -OO at distribution time, we either had to change the behavior of > pythonservice.exe or change the import behavior of Python. While ignoring the question of how Python should in the future handle optimizations, I think it safe to state that that pythonservice.exe should have the same basic functionality and operation in this regard as python.exe does. It doesn't sound too difficult to modify pythonservice to accept -O flags, and to modify the service installation process to allow this flag to be specified. I'd certainly welcome any such patches. Although getting off-topic for this list, note that for recent pywin32 releases, it is possible to host a service using python.exe directly, and this is the technique py2exe uses to host service executables. It would take a little more work to set things up to work like that, but that's probably not too unreasonable for a custom application with specialized distribution requirements. Using python.exe obviously means you get full access to the command-line facilities it provides. So while I believe your idead for getting and setting these flags sounds reasonable, and also believe that at face value the zipimport semantics appear sane, I'm not sure we should use a weakness in a Python tool to justify a change to Python itself. Mark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4