On Sun, 13 Feb 2022 at 14:26, Stephen J. Turnbull
<stephenjturnb...@gmail.com> wrote:
>
> Paul Moore writes:
>
> > Let's keep it simple. I'm -1 on the request, I don't think expandvars
> > should be added to pathlib.
>
> Would you be happier with a getenv_as_path, so that one could do
>
> p = Path.getenv_as_path('HOME') / Path('.python_history')
>
> and on my Mac p == Path('/Users/steve/.python_history')?
I don't think *any* of this is much better than the status quo:
p = Path(os.getenv("HOME")) / ".python_history"
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. 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.
file_next_to_bat_wrapper = os.path.expandvars("%BATFILE_DIR%the_file.txt")
is a Python translation of a *very* common batfile idiom, where %~dp0
is "the directory containing the bat file", which has a trailing
slash, and you need to *not* add an extra slash if you don't want
later filename parsing (in a bat file) to get confused. I can easily
imagine someone who's new to Python using this sort of idiom by
analogy, and then getting bitten by a variable with no trailing slash.
*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. 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'd be surprised if after
doing so, they didn't write their own custom parser (we did for pip,
I'm pretty sure). I think that expending a lot of effort trying to
"improve" expandvars is probably not going to make it much more useful
for that latter group. It might make it more discoverable, and just
possibly more convenient, for people who won't have a problem with its
limitations, but it might *also* make some people who should use a
custom solution, think it's fine and use it when they shouldn't.
To be honest though, I'm not sure of the point of trying to persuade
me. I'm fairly fundamentally opposed to changing anything here, but I
can't express my reservations in a way that will persuade anyone else.
Which is fine. Conversely, if you manage to change my mind, it's not
likely to make much difference - no-one is going to write or merge a
PR purely on the basis that I stopped objecting to the idea ;-)
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/5S2YHOI6Q4AI37ULCU2VYK3NWWEWAVBN/
Code of Conduct: http://python.org/psf/codeofconduct/
