Anthony Baxter wrote: > I'm extremely unconvinced that the semantics of "-m package" or > "-m package.module" are suitably well thought out to see it in b1. This was one of the reasons I wrote execmodule - to figure out semantics which made sense, after my initial attempt at supporting "-m package.module" failed to handle __path__ correctly. Executing anything other than PY_SOURCE or PY_COMPILED modules simply doesn't make sense to me (both execmodule and the current '-m' implementation report errors if you try to do so) > If a single compelling way of making it work can be seen in the > next week, _maybe_ we could sneak it into b2, but I'm really not > hopeful. The approach of 'import the containing package' seems to work fairly well. I can't see any other way to get at the package's __path__ variable in order to locate the module inside it. I haven't seen any good reasons to lift the PY_SOURCE/PY_COMPILED restriction, though. FWIW, the example which convinced me that running modules inside packages was valuable was "python -m pychecker.checker <script>". However, given that execmodule can provide this functionality fairly easily, I voluntarily bumped the relevant patch to Python 2.5 and posted the Cookbook recipe instead. If we do postpone this, I'd suggest putting something in the relevant Python 2.4 "module not found" error message in main.c that notes that packages aren't supported, though (otherwise I expect we'll get at least a few bug reports about not finding modules inside packages). Cheers, Nick.
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