On Sat, Nov 02, 2019 at 07:31:55PM -0400, Eric V. Smith wrote: > On 11/2/2019 7:24 PM, Steven D'Aprano wrote: > >I see no reason why this shouldn't be allowed. It seems like a > >straight-forward feature request, and one that is compatible with the > >basic idea that Path objects should be usable anywhere you need a file > >name. > > The problem is that in the given example, to turn: > `Popen(('/path/to/program', '-o', fspath(outputPath), fspath(inputPath)` > Into this: > `Popen(('/path/to/program', '-o', outputPath, inputPath` > > There's no way for Popen to know that outputPath and inputPath are in > fact file names.
Ah right, yes of course. I was confabulating some imaginary Popen which always took file paths as arguments: Popen(program, outfile, infile ...) but of course that's not the case. Mea culpa. Popen can call any external program, and we shouldn't guess that just because an item in the args sequence is a Path object, the user intended it to be a file path. It could have been a Path object passed in error. > So unless you want to call str() on every element of > args (Popen's first parameter), I don't see how you'd implement this. To be pedantic, we could say "call str() only on Path objects", but special cases aren't special enough (unless they are, but this is not one of the exceptions in my opinion). So on reflection, I agree with you, and withdraw my early comment. -- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OG47WKVAHFPOUNAF4F4CCK2SJJQC6GUY/ Code of Conduct: http://python.org/psf/codeofconduct/