[Thomas H] > That's not what I wanted to hear ;-), but anyway, since you > answered, I assume you have something to do with it. I stuck my finger in it once :) > 1. Modulefinder does not handle cases where packages export names > referring to functions or variables, rather than modules. > Maybe the scan_code method, which looks for IMPORT opcode, > could be extended to handle STORE_NAME opcodes which are not > preceeded by IMPORT opcodes. > > 2. Modulefinder uses imp.find_module to find modules, and > partly catches ImportErrors. imp.find_module can also > raise NameErrors on windows, if the case does not fit. > They should be catched. They both sound fine to me. > 3. Weird idea (?): Modulefinder could try instead of only > scanning the opcodes to actually _import_ modules (at least > extension modules, otherwise it will not find _any_ dependencies). There was some reluctance to do this for freeze, and hence Modulefinder was born. I agree it may make sense in some cases to do this, but it shouldn't be a default action. 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