FWIW, I also agree with Michael that static analysis would be much preferred. You never know what side effects importing a module has. (This could even be construed as an attack vector.) --Guido On Tue, Nov 2, 2010 at 7:54 PM, Brett Cannon <brett at python.org> wrote: > On Tue, Nov 2, 2010 at 17:35, Guido van Rossum <guido at python.org> wrote: >> If you are importing the code, the __module__ attribute on each class >> should tell you where it is actually defined (as opposed to where you >> imported it from). Then sys.modules gives you the module object which >> has a __file__ attribute, etc. > > What Guido said. It's the equivalent of browsing an object that a > function returned to you. Working backwards to where something is > defined has nothing to do with imports and more to do with __module__, > __class__, etc. Import has nothing to do with introspection for things > that you access off of a module that happened to have imported the > object. > >> >> On Tue, Nov 2, 2010 at 4:44 PM, Raymond Hettinger >> <raymond.hettinger at gmail.com> wrote: >>> Brett, Does the import mechanism for importing packages preserve enough information to be able to figure-out where all the components are defined? I'm wondering if it is possible for the class browser to be built-out to scan/navigate class structure across a module that has been split into a package. >> >> -- >> --Guido van Rossum (python.org/~guido) >> > -- --Guido van Rossum (python.org/~guido)
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