[Patches] [ python-Patches-462936 ] Improved modulefinder
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 20 Sep 2001 02:42:07 -0700
Patches item #462936, was opened at 2001-09-19 10:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improved modulefinder
Initial Comment:
This patch adds two improvements to
freeze/modulefinder.
1. ModuleFinder now keeps track of which module is
imported by whom.
2. ModuleFinder, when instantiated with the new
scan_extdeps=1 argument, tries to track dependencies
of builtin and extension modules.
----------------------------------------------------------------------
>Comment By: Thomas Heller (theller)
Date: 2001-09-20 02:42
Message:
Logged In: YES
user_id=11105
The use case is to find as much dependencies as possible.
Sure, you cannot assume that importing an extension module
finds all dependencies - only those which are executed
inside the initmodule function. OTOH, this covers a *lot*
of problematic cases, pygame and numpy for example.
The situation is (somewhat) similar to finding dependencies
of python modules - only those donewith normal import
statements are found, __import__, eval, or exec is not
handled.
A possible solution would be to run the script
in 'profiling mode', where the script is actually run, and
all imports are monitored. This is however far beyond
ModuleFinder's scope.
Hardcoding the knowledge about dependencies into
ModuleFinder for the core modules would be possible
although inelegant IMO. An API for non-standard modules
would be possible, but how should this be used without
executing any code?
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-09-19 13:28
Message:
Logged In: YES
user_id=21627
I dislike the chunk on finding external dependencies. What
is the typical use case (i.e. what module has what
external dependencies)?
It seems easier to hard-code knowledge about external
dependencies into ModuleFinder; this hard-coded knowledge
should cover all core modules. In addition, there should
be an API to extend this knowledge for non-standard
modules.
Furthermore, by executing an import, you cannot be sure
that you really find all dependencies - some may only show
up when a certain function is used.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462936&group_id=5470