> Is there a reason that requires() and files() return iterators instead of lists?

I'm a huge fan of `itertools` and Python 3's move to prefer iterables over materialized lists, and I feel that forcing materialized results gives the caller less control over the results.

Following the same pattern that many standard Python objects return (`open`, `map`, `filter`), the approach is less constrained in that it can support arbitrarily large results. I wished to leave it to the caller to materialize a list if that was needed and my assumption was that 90% of the use-cases would be iterating over the results once.

> I also thought that the APIs accepted either a module or a package name,

Early on, I had hoped to have the API accept either the distribution package name or a Python package... and I even started creating a protocol for package vendors to provide a reference from their module or package back to the distribution package name. But I decided that approach was to invasive and unlikely to get widespread support, but also that it added little value.

What importlib really works with is distribution packages (also known as Projects in PyPI) and not Python packages... and it works at an earlier abstraction (often you want to know metadata about a package without importing it).

> Also consider changing the parameter from files(package) to files(package_name).

I think at one point, the parameter name was distribution_name_or_package. We removed the acceptance of packages, but then renamed the parameter to 'package' for brevity. This parameter is used in many functions (files, requires, version, metadata, distribution). We'd want to change it in all of those. Once it becomes a parameter of the Distribution class (such as in Distribution.from_name), the 'distribution' is implied, so 'name' is clear enough. I do try to avoid long and multi-word parameters when possible. Perhaps more appropriate would be 'distribution_name' or 'dist_name'.

I'm leaning toward 'dist_name' right now. What do you think?