On 2019-11-03 08:24, Steven D'Aprano wrote:
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.
Actually, I'd be OK with Popen accepting path objects. What I was
objecting to was stringifying anything that was passed.
_______________________________________________
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/XNOX5K4BL5FNBIINAYTKRR7DHW4IRAMC/
Code of Conduct: http://python.org/psf/codeofconduct/
