It appears that the `importlib` package has the same issue: One can't
provide an iterator for the path.  When searching a large folder tree for
an item that is likely to be found early in the search process (i.e., at a
high level in the folder tree), the available functionality is massively
inefficient.  So, I wrote my own wrapper for `imp.find_module` to do this
job, and will eventually modify this code to use `importlib` instead of
`imp`.

On Fri, Aug 17, 2018 at 9:05 AM Eric Snow <report@bugs.python.org> wrote:

>
> Eric Snow <ericsnowcurrently@gmail.com> added the comment:
>
> There are several issues at hand here, Phillip.  I'll enumerate them below.
>
> Thanks for taking the time to let us know about this.  However, I'm
> closing this issue since realistically the behavior of imp.find_module()
> isn't going to change, particularly in Python 2.7.  Even though the issue
> is closed, feel free to reply, particularly about how you are using
> imp.find_module() (we may be able to point you toward how to use importlib
> instead).
>
> Also, I've changed this issue's type to "enhancement".  imp.find_module()
> is working as designed, so what you are looking for is a feature request.
> Consequently there's a much higher bar for justifying a change.  Here are
> reasons why the requested change doesn't reach that bar:
>
> 1. Python 2.7 is closed to new features.
>
> So imp.find_module() is not going to change.
>
> 2. Python 2.7 is nearing EOL.
>
> We highly recommend that everyone move to Python 3 as soon as possible.
> Hopefully you are in a position to do so.  If you're stuck on Python 2.7
> then you miss the advantages of importlib, along with a ton of other
> benefits.
>
> If you are not going to be able to migrate before 2020 then send an email
> to python-list@python.org asking for recommendations on what to do.
>
> 3. Starting in Python 3.4, using the imp module is discouraged/deprecated.
>
>   "Deprecated since version 3.4: The imp package is pending deprecation in
> favor of importlib." [1]
>
> The importlib package should have everything you need.  What are you using
> imp.find_module() for?  We should be able to demonstrate the equivalent
> using importlib.
>
> 4. The import machinery is designed around using a list (the builtin type,
> not the concept) for the "module search path".
>
> * imp.find_module(): "the list of directory names given by sys.path is
> searched" [2]
> * imp.find_module(): "Otherwise, path must be a list of directory names"
> [2]
> * importlib.find_loader() (deprecated): "optionally within the specified
> path" (which defaults to sys.path) [3]
> * importlib.util.find_spec(): doesn't even have a "path" parameter [4]
> * ModuleSpec.submodule_search_locations: "List of strings for where to
> find submodules" [5]
> * sys.path: "A list of strings that specifies the search path for modules.
> ... Only strings and bytes should be added to sys.path; all other data
> types are ignored during import." [6]
>
>
> [1] https://docs.python.org/3/library/imp.html#module-imp
> [2] https://docs.python.org/3/library/imp.html#imp.find_module
> [3] https://docs.python.org/3/library/importlib.html#importlib.find_loader
> [4]
> https://docs.python.org/3/library/importlib.html#importlib.util.find_spec
> [5]
> https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec.submodule_search_locations
> [6] https://docs.python.org/3/library/sys.html#sys.path
>
> ----------
> nosy: +brett.cannon, eric.snow
> resolution:  -> wont fix
> stage:  -> resolved
> status: open -> closed
> type: behavior -> enhancement
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue34417>
> _______________________________________
>