On Fri, Feb 11, 2022 at 5:44 PM Chris Angelico <ros...@gmail.com> wrote:
> On Sat, 12 Feb 2022 at 09:34, Ricky Teachey <ri...@teachey.org> wrote:
> >
> > On Fri, Feb 11, 2022 at 4:58 PM MRAB <pyt...@mrabarnett.plus.com> wrote:
> >>
> >> On 2022-02-11 20:05, Ricky Teachey wrote:
> >> > Just had a thought kernel: what if there were an f-string
> mini-language
> >> > directive to grab environment variables and expand user paths? That
> >> > seems to me like it could be even more useful beyond just working with
> >> > paths.
> >> >
> >> > Maybe something like:
> >> >
> >> > f"{my_var:$}"
> >> >
> >> > This would return the same as os.path.expandvars("$my_var")
> >> >
> >> No, that would be the value of the Python variable 'my_var' with the
> >> format string "$".
> >
> >
> > well right now $ is not a valid format string for f-strings. what i'm
> suggesting is to add $ to the format spec mini-languagem and have the
> result be an expanded environment variable value.
> >
> > but you're right, i guess it would apply this to the contents of the
> variable my_var, not the STRING my_var. so maybe the spelling would need to
> use a nested quotation, like this:
> >
> > f"{'my_var':$}"
> >
> > this would be the same as os.path.expandvars("$my_var")
> >
>
> Why shoehorn it into f-strings? Even worse: Why should f-strings fetch
> external information in such a hidden way?
>
> One thing I'm not fully aware of here is what precisely is wrong with
> the status quo. Are you looking for a method instead of a function? Do
> you need something that takes a Path and returns a Path? The existing
> os.path.expandvars will happily accept a Path and return a str:
>
> >>> import pathlib, os.path
> >>> pathlib.Path("$HOME/cpython/Grammar/python.gram")
> PosixPath('$HOME/cpython/Grammar/python.gram')
> >>> os.path.expandvars(pathlib.Path("$HOME/cpython/Grammar/python.gram"))
> '/home/rosuav/cpython/Grammar/python.gram'
> >>> type(_)
> <class 'str'>
>
> I'm confused, since anything involving f-strings clearly has nothing
> to do with pathlib (other than in the trivial sense that you could
> expand vars before constructing a Path), but the OP was very
> definitely talking about Path objects.
>
> ChrisA
>
yes but path objects are usually constructed from a string, and you could
support path objects easily in the f-string using my suggested ~ format
specifier:
Path(f"{my_path_obj:~}")
granted this is a bit weird since you're going from a path obj, to a
string, and back to a path obj again.
i thought of the idea because Serhiy Storchaka brought up the point that
the two expand methods that currently live in os.path have more to do with
strings than they do paths. because of this f-strings seemed to me like a
potentially convenient place to put this functionality. doesn't feel like a
shoehorn at all.
but i suppose in practice, producing an expanded path like above doesn't
seem all that useful. so it's an idea in search of a use case, which means
is probably isn't a very good idea.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
_______________________________________________
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/DPKBNOKG4TO5I326ZCWPXRM4W2BUIQHP/
Code of Conduct: http://python.org/psf/codeofconduct/
