[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 passing a path to ls as argument.
And when I do either of these in Python:
os.listdir(os.path.expanduser('~/code/'))
os.listdir(os.path.expandvars('${HOME}/code/'))
I am still passing a path to listdir. Its just not a pathlib.Path
instance, but it is still a path, just as "123 Main Road" is a street
address and "Jane Doe" is a name.
Of course environment variables are not restricted to being path
components, but neither are Paths:
>>> snake = Path('Chordata/Reptilia/Squamata/Serpentes')
>>> python = snake/'Pythonidae/Python'
>>> rock_python = python/'sebae'
>>> burmese_python = python/'bivittatus'
Is this an abuse of Path? Hell yes. What are we, the Path Police? :-)
The point is, regardless of whatever odd non-path-like things people
might happen to have in environment variables, they also have paths in
environment variables, and it is a strange lack that pathlib doesn't
make it easy to construct paths from environment variables.
If people want to shoot themselves in the foot:
myfile = Path('${HOME}/${LS_COLORS}/file.txt').expandvars()
that's up to them, and who knows, maybe somebody does actually have a
file with that path, no matter how odd it looks.
> Note that there are two implementations of expandvars(): in posixpath
> and ntpath. You may want to apply Posix substitution on Windows and
> Windows substitution on Linux or macOS, so it cannot be tied to
> PosixPath or WindowsPath.
That's odd. I would expect PosixPath.expandvars to use Posix-style
substitution, and WindowsPath.expandvars to use Windows-style
substitution.
--
Steve
___
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/L4V7CC3H7XQFSGQWWZSK4H3MSQBGOPCA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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@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/IWKDMEUHSVYAJG6WNBQSZFFK7AAPBOJF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 ___ 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/CMVCPDJDGQ254CYFV4JHIHS62IEMUMND/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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, 2022 at 6:01 PM Eric V. Smith wrote:
> 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
>> > 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.
>
> Off topic: there are no characters that are invalid format strings, except
> '!' and ':'. For example, datetime allows anything, since it's passed on to
> strftime:
>
> >>> from datetime import date
> >>> f'{datetime.now():This is a test $@$&*()}'
> 'This is a test $@$&*()'
>
> Or:
>
> >>> class F:
> ... def __format__(self, fmt):
> ... if fmt == '$':
> ... return 'dollar'
> ... return 'something else'
> ...
> >>> f'{F():$}'
> 'dollar'
> >>> f'{F():x}'
> 'something else'
>
> Eric
> ___
> 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/JGZAU2A7EQIMTOWPTMTNRLRIBDTK4BJX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
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/DNNTUWCFGRBAXRTTO6PGYXDHCDONG474/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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
> 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.
Off topic: there are no characters that are invalid format strings,
except '!' and ':'. For example, datetime allows anything, since it's
passed on to strftime:
>>> from datetime import date
>>> f'{datetime.now():This is a test $@$&*()}'
'This is a test $@$&*()'
Or:
>>> class F:
... def __format__(self, fmt):
... if fmt == '$':
... return 'dollar'
... return 'something else'
...
>>> f'{F():$}'
'dollar'
>>> f'{F():x}'
'something else'
Eric
___
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/JGZAU2A7EQIMTOWPTMTNRLRIBDTK4BJX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
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 before asking for it. The error message is in property_descr_set() in Objects/descrobject.c. I agree that it should state that the attribute is a property. Python developers know that a property requires a getter, setter, and deleter method in order to function like a regular, mutable attribute. If not, help(property) explains it all clearly. ___ 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/WBQZMFZT4KCXKEUEND4BNAZFAAUA7HA2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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
> >> > 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(_)
>
>
> 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/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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
>> > 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(_)
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
___
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/J4Y335LUOAC2MT74BQT7YLRJVU4CBTLX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 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")
---
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/M73QONQ3HHC2WZN4R657SUDWHWM5L6VK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 "$".
I am not sure about user name expansion though. Maybe something like:
f"{user:~}"
...would return the user directory, and this:
f"{:~}"
...would give the same result as os.path.expanduser("~")
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going
home or actually going home." - Happy Chandler
On Fri, Feb 11, 2022 at 2:04 PM Paul Moore > wrote:
On Fri, 11 Feb 2022 at 16:37, Christopher Barker
mailto:python...@gmail.com>> wrote:
>
> On Fri, Feb 11, 2022 at 12:28 AM Serhiy Storchaka
mailto:storch...@gmail.com>> 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 docs talk about
paths, and it is useful for paths -- so it seems a fine idea to have
that functionality in pathlib.
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 and expects the result to be a file in a
directory called d2. Yes, I know that the documentation could make
this clear (the docs in os.path don't, BTW) and I know that it's no
different than the os.path version, but adding an expandvars method to
pathlib feels like throwing good money after bad...
Let's leave it where it is and keep the status quo, or fix it
*properly* and put it somewhere more logical like shlex. Personally I
don't use it that often, so I'm fine with just leaving it alone.
___
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/FYGLY7P5PUUUAZPGE5FITJO2PXPIF2P5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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")
I am not sure about user name expansion though. Maybe something like:
f"{user:~}"
...would return the user directory, and this:
f"{:~}"
...would give the same result as os.path.expanduser("~")
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
On Fri, Feb 11, 2022 at 2:04 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
> >> variables consists of three distinct steps:
> >
> > sure -- but it does live in os.paths now, the docs talk about paths, and
> it is useful for paths -- so it seems a fine idea to have that
> functionality in pathlib.
>
> 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 and expects the result to be a file in a
> directory called d2. Yes, I know that the documentation could make
> this clear (the docs in os.path don't, BTW) and I know that it's no
> different than the os.path version, but adding an expandvars method to
> pathlib feels like throwing good money after bad...
>
> Let's leave it where it is and keep the status quo, or fix it
> *properly* and put it somewhere more logical like shlex. Personally I
> don't use it that often, so I'm fine with just leaving it alone.
>
> 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/2XSYXAFLMMVGJDYJYRM2CDZO2WV5YDX6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/IGI5FKZAR62T63JKEC4JTOCRXLVJGTT2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
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 knowing to think "it's a property, stupid!" was the hard part > and just stating that in the error message would have saved me the > frustration. 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 before asking for it. 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/FSKUTUAMA4A4EK5BN7UPCHZ3D4GF6X74/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 distinct steps:
>
> sure -- but it does live in os.paths now, the docs talk about paths, and it
> is useful for paths -- so it seems a fine idea to have that functionality in
> pathlib.
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 and expects the result to be a file in a
directory called d2. Yes, I know that the documentation could make
this clear (the docs in os.path don't, BTW) and I know that it's no
different than the os.path version, but adding an expandvars method to
pathlib feels like throwing good money after bad...
Let's leave it where it is and keep the status quo, or fix it
*properly* and put it somewhere more logical like shlex. Personally I
don't use it that often, so I'm fine with just leaving it alone.
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/2XSYXAFLMMVGJDYJYRM2CDZO2WV5YDX6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
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 just stating that in the error message would have saved me the frustration. On Fri, Feb 11, 2022 at 2:46 AM Neil Girdhar wrote: > 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 base class. >> >> > Would it make sense to mention the reason why the attribute can't be >> set, >> > namely that it's on a property without a setter? >> >> I have no objection to changing the error message, I'm sure it's a small >> enough change that you should just open a ticket on b.p.o. for it. But I >> don't expect that it will be particularly useful either. >> >> If you can't set an attribute on an object, aren't there three obvious >> causes to check? >> >> - the object has no __dict__, and so has no attributes at all; >> e.g. trying to set an attribute on a float; >> >> - the object has slots, but 'f' is not one of them; >> >> - or 'f' is a property with no setter (or a setter that raises >> AttributeError). >> >> Have I missed any common cases? >> >> The error messages are different in each case, but even if they were the >> same, there are three obvious causes to check, and property is one of >> them. >> >> I suppose that there are exotic failures that could happen in >> __getattribute__ or weird descriptors, or metaclass magic, etc, and >> *those* might be hard to debug, but it doesn't seem likely to me that a >> read-only property will be mysterious. >> >> Especially if you have the object available in the interactive >> interpreter, so you can inspect it with the various tools available: >> >> * dir(obj) >> * help(obj) >> * type(obj).f # Will display >> >> etc. Its hard to keep the existence of a property secret in Python. >> >> So once you know that f is a property, it might be hard to work out >> which of the fifty-seven superclasses and mixins it came from *wink* but >> that's neither here nor there :-) >> >> Maybe reporting "can't set property 'f'" is good enough. >> >> >> -- >> Steve >> ___ >> 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/Z2AWWETWB72CKARR4DAHB3A2LFRLQR7X/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "python-ideas" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/python-ideas/IMzPQhK64lw/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> python-ideas+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python-ideas/20220211093720.GO16660%40ando.pearwood.info >> . >> > ___ > 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/UW3D64ROFVSOEW6G6B3JTMB67ERRWW5D/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/MKZLRYNTHSR5TU7NB3LYLAGUHVQKLWG3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 docs talk about paths, and it is useful for paths -- so it seems a fine idea to have that functionality in pathlib. Note that there are two implementations of expandvars(): in posixpath > and ntpath. You may want to apply Posix substitution on Windows and > Windows substitution on Linux or macOS, so it cannot be tied to > PosixPath or WindowsPath. > I'm a bit confused here: in os.path it's tied to posixpath or ntpath, so what is it any different to tie it to PosixPath or WindowsPath? Also, IIUC, it expands environment variable from the current environment -- so expanding an environment variable from a non-native system seems pretty esoteric. Perhaps the shlex module would more appropriate place for expandvars() > than os.path, but what done is done. > How about we add it to shlex for the more general (and esoteric) cases, and also add it to pathlib for the path cases? Yes, having essentially the same thing in three places is not-good, but pathlib already duplicated much of os.path, that's exactly the point. ANd while we are at it, it could take a flag indicating what style of envvar expnasion to use: % or $ or both. "The easy things should be easy" If a user wants to expand an environment variable in a path, there should be an easy and obvious way to do that. NOTE: I don't think anyone is suggesting that os.path be deprecated -- but I do think it's a worthy goal to be able to do be able to do everything you need to do with pathlib without having to reach back into os.path -- needing both is kind the worst of both worlds. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/J3WQVY63Y5NLKGRLNMJZYMV3G5LUKO3K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
> 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 yes: > > "can't set property 'f'" > > Would be far more clear message. > > -CHB > > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/OS2OPVCCWBQAILROXFOMFQOZTFY2IPLF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
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 yes: "can't set property 'f'" Would be far more clear message. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/A3A5ZZGBRTMQ5WKKKRIEMFQFOQSG4E43/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
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 -- maybe only because it's new, but folks are certainly far more > familiar with **kwargs than pattern matching. Structural pattern matching does a more general assignment than happens at passing of function arguments. So the latter is simpler, but is sufficient (at least conceptually) for the form of assignment considered here. However, both of them may lead to distinct pieces of syntax, both of which might possibly be useful. Best regards, Takuo Matsuoka ___ 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/N6MXW3HNFJBBUY3BCJBQTGA6WGEQGDMI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
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 personally inclined towards marking the assignment target in some
> way, since that would extrapolate conveniently to all other assignment
> types (eg "for match {MATCH_EXPR} in iterable:"), but I don't like the
> specific placeholder example I've used here.
Having special notation for the assignment target sounds like a good
way to me.
Best regards,
Takuo Matsuoka
___
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/3E6MKKC3ZXYR36VRPUMD2PJT5KNLIGST/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
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 base class. > > > Would it make sense to mention the reason why the attribute can't be > set, > > namely that it's on a property without a setter? > > I have no objection to changing the error message, I'm sure it's a small > enough change that you should just open a ticket on b.p.o. for it. But I > don't expect that it will be particularly useful either. > > If you can't set an attribute on an object, aren't there three obvious > causes to check? > > - the object has no __dict__, and so has no attributes at all; > e.g. trying to set an attribute on a float; > > - the object has slots, but 'f' is not one of them; > > - or 'f' is a property with no setter (or a setter that raises > AttributeError). > > Have I missed any common cases? > > The error messages are different in each case, but even if they were the > same, there are three obvious causes to check, and property is one of > them. > > I suppose that there are exotic failures that could happen in > __getattribute__ or weird descriptors, or metaclass magic, etc, and > *those* might be hard to debug, but it doesn't seem likely to me that a > read-only property will be mysterious. > > Especially if you have the object available in the interactive > interpreter, so you can inspect it with the various tools available: > > * dir(obj) > * help(obj) > * type(obj).f # Will display > > etc. Its hard to keep the existence of a property secret in Python. > > So once you know that f is a property, it might be hard to work out > which of the fifty-seven superclasses and mixins it came from *wink* but > that's neither here nor there :-) > > Maybe reporting "can't set property 'f'" is good enough. > > > -- > Steve > ___ > 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/Z2AWWETWB72CKARR4DAHB3A2LFRLQR7X/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "python-ideas" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/python-ideas/IMzPQhK64lw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > python-ideas+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python-ideas/20220211093720.GO16660%40ando.pearwood.info > . > ___ 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/UW3D64ROFVSOEW6G6B3JTMB67ERRWW5D/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
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 without a setter? I have no objection to changing the error message, I'm sure it's a small enough change that you should just open a ticket on b.p.o. for it. But I don't expect that it will be particularly useful either. If you can't set an attribute on an object, aren't there three obvious causes to check? - the object has no __dict__, and so has no attributes at all; e.g. trying to set an attribute on a float; - the object has slots, but 'f' is not one of them; - or 'f' is a property with no setter (or a setter that raises AttributeError). Have I missed any common cases? The error messages are different in each case, but even if they were the same, there are three obvious causes to check, and property is one of them. I suppose that there are exotic failures that could happen in __getattribute__ or weird descriptors, or metaclass magic, etc, and *those* might be hard to debug, but it doesn't seem likely to me that a read-only property will be mysterious. Especially if you have the object available in the interactive interpreter, so you can inspect it with the various tools available: * dir(obj) * help(obj) * type(obj).f # Will display etc. Its hard to keep the existence of a property secret in Python. So once you know that f is a property, it might be hard to work out which of the fifty-seven superclasses and mixins it came from *wink* but that's neither here nor there :-) Maybe reporting "can't set property 'f'" is good enough. -- Steve ___ 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/Z2AWWETWB72CKARR4DAHB3A2LFRLQR7X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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/ in /pathlib/, and > the recommendation seems to be to use /pathlib/ to do any and all path > manipulations, with the exception of expanding environment variables. 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: 1. Represent a path as a string. 2. Expand environment variables in the string. 3. Create a new path from a new string. Note that there are two implementations of expandvars(): in posixpath and ntpath. You may want to apply Posix substitution on Windows and Windows substitution on Linux or macOS, so it cannot be tied to PosixPath or WindowsPath. Perhaps the shlex module would more appropriate place for expandvars() than os.path, but what done is done. ___ 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/DBMBMOWQUPGITFKMMBYVZ2BDOPFBVVKC/ Code of Conduct: http://python.org/psf/codeofconduct/
