> [Thomas] > > Who is maintaining freeze/Modulefinder? > > > > I have some issues I would like to discuss... > > [long silence] > > I guess this make it you then ;-) > That's not what I wanted to hear ;-), but anyway, since you answered, I assume you have something to do with it. > I wouldn't mind seeing this move into distutils as a module others could > draw on. For example, "freeze" could be modifed by the next person game > enough to touch it <wink> to reference the module directly in the distutils > package? > > It keeps the highly useful module alive, and makes "ownership" more > obvious - whoever owns distutils also gets this baggage <wink> Sounds good, but currently I would like to concentrate an technical rather than administrative details. The following are the ideas: 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. 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). Thomas
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