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
On Thu, Feb 10, 2022 at 02:27:42PM -0800, Neil Girdhar wrote:
> AttributeError: can't set attribute 'f'
>
> This can be a pain to debug when the property is buried in a base class.
> Would it make sense to mention the reason why the attribute can't be set,
> namely that it's on a property witho
I humbly disagree that any of what you wrote is "obvious".
On Fri, Feb 11, 2022 at 4:41 AM Steven D'Aprano wrote:
> On Thu, Feb 10, 2022 at 02:27:42PM -0800, Neil Girdhar wrote:
>
> > AttributeError: can't set attribute 'f'
> >
> > This can be a pain to debug when the property is buried in a bas
I'm sorry for the inaccuracy, and thank you for the corrections!
On Fri, 11 Feb 2022 at 01:56, Chris Angelico wrote:
>
> On Fri, 11 Feb 2022 at 00:33, Matsuoka Takuo wrote:
> >
..
>
> But the crucial thing is to figure out the syntax. Without good
> syntax, this is not of interest.
>
> I'm p
On Fri, 11 Feb 2022 at 04:02, Christopher Barker wrote:
>
> Just one note:
>
> On Thu, Feb 10, 2022 at 6:56 AM Chris Angelico wrote:
>>
>> > (2) For the form of the assignment target, I think an analogy with the
>> > reception of function arguments could also be considered.
>
>
> I think so -- ma
I have to say I agree with Neil here. I was trying to think about what
other reasons an attribute might be unsettable, and did not quickly come up
with that list.
And after reading your list, I tried to imagine what I’d tell my beginning
students !
But if the error message is indeed unique then y
> I have to say I agree with Neil here. I was trying to think about what
> other reasons an attribute might be unsettable, and did not quickly come up
> with that list.
>
> And after reading your list, I tried to imagine what I’d tell my beginning
> students !
>
> But if the error message is indeed
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
Yeah, I have to agree with Neil. I had exactly this issue a couple years
ago, and it took me an hour or two to figure out that it was a
property/descriptor-protocol causing the issue, at which point the fix
became trivial. Just knowing to think "it's a property, stupid!" was the
hard part and jus
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, 11 Feb 2022 at 18:36, Eric Fahlgren wrote:
>
> Yeah, I have to agree with Neil. I had exactly this issue a couple years
> ago, and it took me an hour or two to figure out that it was a
> property/descriptor-protocol causing the issue, at which point the fix became
> trivial. Just know
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 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:
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 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 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 2/11/22, Paul Moore wrote:
>
> I'm inclined to say just raise an issue on bpo. If it's easy enough,
> it'll just get done. If it's hard, having lots of people support the
> idea won't make it any easier. I don't think this is something that
> particularly needs evidence of community support bef
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
>
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 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
___
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 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
22 matches
Mail list logo
