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 wrote:
> On Tue, Nov 2, 2010 at 17:35, Guido van Rossum
On Tue, Nov 2, 2010 at 17:35, Guido van Rossum 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,
On 02/11/2010 23:44, Raymond Hettinger 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 struct
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.
On Tue, Nov 2, 2010 at 4:44 PM, Raymond Hettinger
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
