While I agree with the logic, it is probably an overkill to create a generator function just for this purpose. It would be much readable to merge this into the previous filter call.

HI @uranusjr, thanks for taking the time to review but I disagree that creating a separate function for this is overkill, as it has the advantage that the intent of the action is explicit: the reader can simply choose to trust that the function skips commented lines without having to know the implementation. On the other hand, extending the filter predicate might look something like this:

    installed_packages = filter(
        lambda line: line and not line.lstrip().startswith('#'),
        delegator.run('{0} freeze'.format(which_pip())).out.strip().split(
            '\n'
        ),
    )

Here there reader is presented with the "how", and needs to figure out the "what".

This pull request is actually cut down to a minimal change from a larger set of changes where pip freeze output is treated in a more consistent manner which would justify having this in one place to prevent re-use. As a first-time contributor to this project however, I wasn't going to push up a pull request that touched many parts of the core (at a glance it looks like lock, purge, clean, and outdated all use the output of pip freeze but only purge handles this, see #1268) without first becoming more familiar with the testing and the codebase so that we could all be confident that such a refactor wouldn't break anything existing.

@nelfin There is a middle ground between filtering + iterator and a lambda:

def is_requirement_line_useful(line):
    line = line.strip()
    if not line:
        return False
    if not line.startswith('#'):
        return False
    return True

installed_packages = filter(
    is_requirement_line_useful,
    delegator.run('{0} freeze'.format(which_pip())).out.split('\n'),
)

(Personally I’d prefer a generator to filter in this case, but that’s only my preference.)

+1 to generator, filter is hard to understand/maintain