On Mon, 14 Feb 2022 at 02:34, Paul Moore <p.f.mo...@gmail.com> wrote: > The main point I see of expandvars is to have a way of letting the > *user* pass a string that might reference environment variables, and > expand them. There's some problematic aspects of that already, namely > the platform-dependent handling of % symbols.
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. > I assume that the > intended use case for expandvars, based on the fact that it's in > os.path, is to allow expansion of a variable containing a directory > name, such as $HOME, as in the example you give. And that's mostly > fine. Windows has some weirdness in that some environment variables > can (I think) contain trailing backslashes (it definitely happens with > batch file substitution variables, I haven't been able to find an > example with environment variables, but I wouldn't bet either way, > given how the extremely limited capabilities of batch files can get > used to (clumsily) set environment variables at time (look at some of > the wrapper scripts for Java apps, for examples). Again, that's > probably fine, as sequences of multiple slashes and backslashes should > get normalised. But again, I wouldn't be 100% sure. Not sure, but if there are issues with the way that Python on Windows expands variables, they can be raised as bugs. > *shrug* As I say, my arguments are mostly "from experience" and "vague > concerns" - which people, notably the other Steven, have dismissed > (with some justification). Generally, I think that expandvars is > mildly risky, but perfectly fine for simple use. And perfectly fine for strings provided by the user. In fact, it's extremely frustrating to work with a program that DOESN'T do proper var and user expansion - I expect "~git/reponame/.git" to expand to the home directory of the git user, not my home directory with the word "git" after it. As long as Python's expanduser/expandvars behave as per platform expectations, the risk is on the user, not on the script. > People wanting to > write high-reliability production code should probably think a bit > harder about what they actually want, and whether the limitations of > expandvars are acceptable for their needs. I want my users to be able to treat my script the way they treat everything else in the system. Not sure what you mean by "limitations of expandvars". It does precisely what it is supposed to do. The only problem is that it always returns a str or a bytes, not a Path, so you'd have to then construct a Path. On the other hand, if you're writing something where platform is irrelevant, then expandvars isn't just limited, it's actually wrong, and you should be doing expansion differently. ChrisA _______________________________________________ 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/XZR2QGX7WUWIGGDELGNGUL7O6JYZTV3G/ Code of Conduct: http://python.org/psf/codeofconduct/
