> 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.

My recommendation is to return a concrete list.  Shifting the responsibility to the user makes the API less convenient, particularly if someone is running this at the interactive prompt and just wants to see the results.

We replaced the list version of map() with itertools.imap() for memory efficiency with potentially enormous or infinite inputs.  However, this came at a cost for usability.  In every single course where I present map() there is an immediate stumble over the need to wrap it in list() just to see the output.  In general, we should save the iterators for cases where there is real value in lazy execution.  Otherwise, usability, inspectability, sliceability, and re-iterability wins.  (Just think of how awkward it would be if dir() or os.listdir() returned an iterator instead of a list.)

FWIW, the doc string for requires() is:

   Return a list of requirements for the indicated distribution


> Perhaps more appropriate would be 'distribution_name' or 'dist_name'.

I recommend 'distribution_name'.  It will normally be used as a positional parameter but the full name will show-up in the tool tips, providing guidance on how to use it.



When you get a chance, please look at https://github.com/python/cpython/pull/15204
where I'm presenting your creation to the world.

Overall, I think this was a nice addition to the standard library.  Thanks for your work :-)