On 11/2/2019 10:02 PM, Jonathan Goble wrote:
On Sat, Nov 2, 2019 at 9:52 PM MRAB <pyt...@mrabarnett.plus.com> wrote:
On 2019-11-03 00:38, Chris Angelico wrote:
On Sun, Nov 3, 2019 at 11:34 AM Eric V. Smith <e...@trueblade.com> 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. 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.
I wouldn't see a problem with that. It'd mean you can also pass an
integer as an argument, and it'd be sent as digits. I've wanted that a
number of times too.
It would also let you pass a whole load of other things too. It would
accept x if str(x) returns a string ... which means _anything_. Lists,
dicts, compiled regexes, ....
My response is "don't do that." :-P
I think the principle of consenting adults applies. Seems pretty
obvious that if you pass random junk to a command not designed to
accept it, then anything could happen. Or as they say, "garbage in,
garbage out".
I don't know why we'd want garbage out instead of failing.
I really don't think this would be misused, at least not without
immediately getting errors, and there's no hidden "gotcha" (at least
on the surface) that makes it difficult to realize what's wrong. If
the arguments to the command don't make sense, you're almost always
going to immediately get errors.
"Almost always" isn't good enough.
So there's no reason in that regard to not allow it, and I'm +1 on the idea.
I disagree. I don't think there's precedent in Python for stringifying
parameters. By your logic, shouldn't we also call str() on the
parameters for str.join()? Or how about ord()? (Oops, I accidentally
called len: "s='3'; ord(len(n))".) Or the first parameter of open()? (Do
we really want "open(fn_that_might_occasionally_return_none(), 'w')" to
succeed?)
If you really want versions of functions that stringify their parameters
and will hide such errors, just write your own wrappers.
I'm -1. This would open the door to errors passing through instead of
being raised.
Eric
_______________________________________________
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/U564BECCUUQEXLTV5HIH2AA5734BWFHY/
Code of Conduct: http://python.org/psf/codeofconduct/
