> I don't think file is a good name.

Changed to "cmd" for command, and that's what the Unix `which` calls it as well.

> Wait, why are we even returning more than one result?  I don't see any use cases for that in the issue (though I admit I just skimmed it).  The unix which command doesn't.

I guess I just stuck with what was always there, or maybe I introduced it back in an earlier patch - can't remember. In any case, thanks for mentioning this because the common case really is just wanting one path. `which -a` prints all instances on the path, but that'd be an additional and less-used case for sure.

> Given that the function works on Windows, its behavior (looking in the current directory and in PATHEXT) should be documented.  And if that's not what exec*p* does on windows, that should be noted, I think (or fixed?)

Documented.

> I'm also not sure what the 'path' argument is for.  Does it have a use case?  If not, drop it.

I've needed this myself when maintaining systems that need to start executables via subprocess.Popen using a Path from a configuration file or other inputs. When I'd need to setup a Path which included a lot of dependencies, like for a mini-continous integration system we had, it would be nice to know where the "foo" command was coming from in my temporary build environment.

> You are doing the PATHEXT extraction regardless of platform, which I don't think is a good idea.

Changed, it's Windows specific now. I will have access to a linux box to test this out tomorrow morning, but I think the patch should work there.

> This line appears to be useless:

Removed, that must have been from an old iteration.

> Per my suggestion of dropping the list form (at least for now), the yield should become a return, with the default return value of None indicating not found.

Done. It's all returns now including a default of None.