On 2/13/22, Eric Fahlgren wrote:
>
> That may or may not work as Windows has inconsistent treatment of multiple
> separators depending on where they appear in a path. If TEMP is a drive
> spec, say "t:\", then it expands to "t:\\spam.csv", which is an invalid
> windows path. If TEMP is a directo
On 2/13/22, Paul Moore wrote:
>
> 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
You're overlooking ExpandEnvironmentStringsW() [1],
ExpandEnvironmentStringsForUserW(), and PathUnExpandEnvStringsW() [2],
w
On Mon, 14 Feb 2022 at 05:15, Eric Fahlgren wrote:
>
> On Sun, 13 Feb 2022 at 15:43, Chris Angelico wrote:
>>
>> > 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 t
On Sun, 13 Feb 2022 at 15:43, Chris Angelico wrote:
> > 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
On Sun, 13 Feb 2022 at 15:43, Chris Angelico 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
On Mon, 14 Feb 2022 at 02:34, Paul Moore 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 %
On Sun, 13 Feb 2022 at 14:26, Stephen J. Turnbull
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')
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
On Sun, 13 Feb 2022 at 21:47, Paul Moore wrote:
>
> On Sun, 13 Feb 2022 at 01:09, Steven D'Aprano wrote:
>
> > I'm sorry Paul, but this sort of made-up, utterly artificial toy example
> > adds no benefit to the discussion, it just adds fear, uncertainty and
> > doubt to an extremely straight-forw
On Sun, 13 Feb 2022 at 01:09, Steven D'Aprano wrote:
> I'm sorry Paul, but this sort of made-up, utterly artificial toy example
> adds no benefit to the discussion, it just adds fear, uncertainty and
> doubt to an extremely straight-forward feature request.
OK, if that's your view then fine. I a
On Fri, Feb 11, 2022 at 07:01:12PM +, Paul Moore wrote:
> One way that tying it to paths is bad is that it ignores the path
> structure. If environment variable a is "d1/f1" and b is "d2/f2" then
> "${a}x${b}" is "d1/f1xd2/f2", which could be very confusing to someone
> who sees the value of b
On Sun, 13 Feb 2022 at 03:15, Paul Moore wrote:
>
> On Sat, 12 Feb 2022 at 16:02, Chris Angelico wrote:
> >
> > On Sun, 13 Feb 2022 at 02:57, Eric V. Smith wrote:
> > > See Paul’s example, copied above. Maybe the code isn’t expecting it.
> > >
> >
> > There wasn't an actual example, just a hypot
On Sat, 12 Feb 2022 at 16:02, Chris Angelico wrote:
>
> On Sun, 13 Feb 2022 at 02:57, Eric V. Smith wrote:
> > See Paul’s example, copied above. Maybe the code isn’t expecting it.
> >
>
> There wasn't an actual example, just a hypothetical one. I have never
> once seen something in real usage whe
On Sun, 13 Feb 2022 at 02:57, Eric V. Smith wrote:
> See Paul’s example, copied above. Maybe the code isn’t expecting it.
>
There wasn't an actual example, just a hypothetical one. I have never
once seen something in real usage where you interpolate environment
variables into a path, without expe
> On Feb 12, 2022, at 10:54 AM, Chris Angelico wrote:
>
> On Sun, 13 Feb 2022 at 02:45, Eric V. Smith wrote:
>>
>>
>>> On 2/11/2022 2:01 PM, Paul Moore wrote:
>>> On Fri, 11 Feb 2022 at 16:37, Christopher Barker
>>> wrote:
On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka
wrote
On Sun, 13 Feb 2022 at 02:45, Eric V. Smith wrote:
>
>
> On 2/11/2022 2:01 PM, Paul Moore wrote:
> > On Fri, 11 Feb 2022 at 16:37, Christopher Barker
> > wrote:
> >> On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka
> >> wrote:
> >>> expandvars() does not operate on paths, it operates on strin
On 2/11/2022 2:01 PM, Paul Moore wrote:
On Fri, 11 Feb 2022 at 16:37, Christopher Barker wrote:
On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka wrote:
expandvars() does not operate on paths, it operates on strings and
bytestrings. There is nothing path-specific here. Expanding environment
On Fri, Feb 11, 2022 at 10:26:03AM +0200, Serhiy Storchaka wrote:
> expandvars() does not operate on paths, it operates on strings and
> bytestrings. There is nothing path-specific here.
Paths can be strings and byte-strings too.
When I using my OS shell, and I type:
ls -l ~/code/
I am pas
On Fri, Feb 11, 2022 at 08:59:57PM -0500, Eric V. Smith wrote:
> there are no characters that are invalid format strings,
> except '!' and ':'.
Thank you for reminding us (including me) of this.
--
Steve
___
Python-ideas mailing list -- python-ideas
On Fri, Feb 11, 2022 at 03:05:47PM -0500, 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?
f-strings make good hammers.
Not everything is a nail.
--
Steve
___
you can already put an arbitrary expression in a f-string -- that's the
point. So what's wrong with:
In [12]: eget = os.environ.get
In [13]: f"{eget('HOME')}/bin"
Out[13]: '/Users/chris/bin'
This seems a rare enough need that special built-in support is not worth it.
-CHB
On Fri, Feb 11, 20
On 2/11/2022 5:33 PM, Ricky Teachey wrote:
On Fri, Feb 11, 2022 at 4:58 PM MRAB 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
>
On Fri, Feb 11, 2022 at 5:44 PM Chris Angelico wrote:
> On Sat, 12 Feb 2022 at 09:34, Ricky Teachey wrote:
> >
> > On Fri, Feb 11, 2022 at 4:58 PM MRAB wrote:
> >>
> >> On 2022-02-11 20:05, Ricky Teachey wrote:
> >> > Just had a thought kernel: what if there were an f-string
> mini-language
> >
On Sat, 12 Feb 2022 at 09:34, Ricky Teachey wrote:
>
> On Fri, Feb 11, 2022 at 4:58 PM MRAB 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
On Fri, Feb 11, 2022 at 4:58 PM MRAB 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
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:
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.expa
On Fri, 11 Feb 2022 at 16:37, Christopher Barker wrote:
>
> On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka wrote:
>>
>> expandvars() does not operate on paths, it operates on strings and
>> bytestrings. There is nothing path-specific here. Expanding environment
>> variables consists of three d
On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka
wrote:
> expandvars() does not operate on paths, it operates on strings and
> bytestrings. There is nothing path-specific here. Expanding environment
> variables consists of three distinct steps:
>
sure -- but it does live in os.paths now, the do
10.02.22 12:59, anthony.flury via Python-ideas пише:
> I know that /os.path/ includes a function /expandvars(..)/ which expands
> any environment variables in a given path, but from looking at the
> /pathlib/ documentation It seems there is
> no equivalent to /os.path.expandvars(..) on any class/ i
FYI there was a patch for this in the past and it was rejected:
https://bugs.python.org/issue21301
Damian (he/him)
On Thu, Feb 10, 2022 at 12:04 PM Christopher Barker
wrote:
> +1 -- I would really like pathlib to be able to used for everything one
> would need to do with paths.
>
> -CHB
>
>
> O
+1 -- I would really like pathlib to be able to used for everything one
would need to do with paths.
-CHB
On Thu, Feb 10, 2022 at 3:05 AM anthony.flury via Python-ideas <
python-ideas@python.org> wrote:
> All,
>
> I know that *os.path* includes a function *expandvars(..)* which expands
> any en
32 matches
Mail list logo
