On Sun, 13 Feb 2022 at 15:43, Chris Angelico <ros...@gmail.com> wrote:
>
> Which is why the default should be to follow platform expectations. If
> I pass a parameter to a script saying "~/foo/bar", that script should
> be able to expanduser/expandvars to make that behave the way I expect
> it to. If I'm on Windows and I tell something to write to a file in
> "%TEMP%\spam.csv", then I expect it to understand what that means.
> Cross-platform support is nice, but the most common need is for the
> current platform's normal behaviour.
For better or worse, though, Windows (as an OS) doesn't have a "normal
behaviour". %-expansion is a feature of CMD and .bat files, which
varies depending on the Windows version and the version of CMD. A
significant proportion of command line programs on Windows are ported
from Unix and add (some form of) Unix-like behaviour, either as well
as, or instead of, % expansion. Remember, I'm supporting the existing
behaviour as "good enough" here. I'm not the one advocating change. If
you believe that "the current platform's normal behaviour" is anything
other than what os.path.expandvars does, then the onus is on you to
define what you mean.
But I thought the debate here was about "putting a version of
expandvars into pathlib". Maybe someone ought to define what that
means, in practice.
Oh, and just for fun, I just discovered that expandvars does (arguably
broken) quoting, too:
>>> os.path.expandvars("$USERNAME")
'Gustav'
>>> os.path.expandvars("'$USERNAME'")
"'$USERNAME'"
>>> os.path.expandvars("'%USERNAME%'")
"'%USERNAME%'"
Note that it *keeps* the quotes. That's *definitely* not normal
platform behaviour on Windows...
But anyway, I thought the debate here was about "putting a version of
expandvars into pathlib". Maybe someone ought to define what that
means, in practice.
Remember to make sure that the documentation of Path.expandvars()
makes it clear why (Path("Dev team's docs") / Path("${USER}'s files")
/ Path("somefile.txt")).expandvars() returns Path("Dev team's
docs/${USER}'s files/somefile.txt") and not Path("Dev team's
docs/Gustav's files/somefile.txt"), so that people don't report it as
a bug... Yes, they might do the same with os.path.expandvars, but
that's easily responded to - "documentation bug, the docs should
mention quoting and should emphasise that the operation treats the
argument as a string, not as a path". I'm not sure the same response
works when it's a method of a Path object ;-)
And I repeat, *please* remember that I'm not the one arguing for
change here, I'm arguing that the proposed change is potentially more
complex than people are suggesting, and that actually, the benefit
isn't sufficient to justify the work. Although as it's not clear yet
who is offering to do the work, it may be premature of me to make that
argument...
Paul
_______________________________________________
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/7VYTLU2MANE4SXNJBRHVBHLHR25NUTE6/
Code of Conduct: http://python.org/psf/codeofconduct/
