[Python-ideas] Re: Please consider mentioning property without setter when an attribute can't be set
On Fri, Feb 11, 2022 at 08:00:54AM -0800, Christopher Barker wrote: > 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. I'm curious what list you came up with if it excluded the three cases I suggested (no __dict__, __slots__, property). What other cases are there? There's dynamic attributes with __getattr__ and __getattribute__, and who knows what can be done with metaclass magic, but I'm impressed and kinda intimidated if they are what came to mind *before* objects without a dict :-) > And after reading your list, I tried to imagine what I’d tell my beginning > students ! Tell them in what context? Have you already covered properties? If so, then it should be fairly obvious what to tell them: "Class, what do you think will happen if you have a property with no setter and you try to set its value?" If your class is experienced enough to have learned about classes and properties, they will surely guess some sort of exception will happen. > But if the error message is indeed unique then yes: > > "can't set property 'f'" > > Would be far more clear message. As I said, I don't object to the change in wording if it is easy enough to implement. -- 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/47FMU4SUWVULMOBO7HRTXLUJE5LKQAIV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 and expects the result to be a file in a
> directory called d2.
"Very confusing". Huh. Maybe they would be less confused if they would
look at the entire path expression, instead of just the ${b} envar in
isolation.
Real environment variables are not usually called "${a}", they have
names that reflect their meaning. And they typically have values which
are more meaningful than "d1/f1".
Real environment variables can be file names, or suffixes or prefixes,
or directiory components, but your example where ${a} combines a
directory component with a prefix, and ${b} combines a suffix with a
file name, is surely a terrible design. Who would do that?
No wonder you gave them single letter names, it would be awful to have
to come up with a descriptive name for doing this. Or a use-case.
But that's okay, people use terrible designs all the time. It is not our
job to protect them from themselves. If it was, Python wouldn't have
metaclasses, or classes, or functions, or variables, or code.
The conclusion you would like us to draw from this invented example is
that we should forego supporting envars in pathlib because of the
miniscule risk that somebody using a really shitty design with badly
thought-out envars might be confused by one of the envars in isolation.
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.
--
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/O2XYTOLQG4A27P5QYAOVQDH5JUEFPFE3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 hypothetical one. I have never
> > once seen something in real usage where you interpolate environment
> > variables into a path, without expecting the environment variables to
> > be paths.
> >
> > It's different with URLs, but pathlib doesn't handle URLs, it handles paths.
>
> My example was not intended to illustrate that having slashes within
> variables wasn't reasonable, but rather that concatenating a string to
> a variable without an intervening slash *could* be confusing. But
> equally it might not be:
>
> backup = os.path.expandvars("${ORIGFILE}.bak")
>
> The point I was trying to make is that thinking of expandvars as
> acting on strings is straightforward, whereas thinking of the operands
> as paths can lead to expectations that might be wrong. I'm arguing
> that we should not link expandvars with paths, even though
> historically it's part of os.path.
>
That's fair, but I don't know of any situation where ORIGFILE would
come from an environment variable but be required to be a file name
without a path. For instance, if you have an env var saying "put the
backup over here", then it most certainly could be used the way you
describe, but then the normal expectation would be for it to allow a
full path.
Much more common, for the expansion you're describing, would be for
ORIGFILE to come from elsewhere in the code, so expandvars is
irrelevant.
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/LLZNFYWVBXV7PMFHH2BMJIHCJBANWAIH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 where you interpolate environment
> variables into a path, without expecting the environment variables to
> be paths.
>
> It's different with URLs, but pathlib doesn't handle URLs, it handles paths.
My example was not intended to illustrate that having slashes within
variables wasn't reasonable, but rather that concatenating a string to
a variable without an intervening slash *could* be confusing. But
equally it might not be:
backup = os.path.expandvars("${ORIGFILE}.bak")
The point I was trying to make is that thinking of expandvars as
acting on strings is straightforward, whereas thinking of the operands
as paths can lead to expectations that might be wrong. I'm arguing
that we should not link expandvars with paths, even though
historically it's part of os.path.
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/BDJ6WRBBACUFQIFIUHPE2M5VYAFAVBVF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 expecting the environment variables to be paths. It's different with URLs, but pathlib doesn't handle URLs, it handles paths. 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/QTYY7YHCQLTRLI7VSA3KRC5BNZNEP6XC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
> 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:
> 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.
>>
>> I'd like to see a Path.expandvars(), something like:
>>
>> --
>>
>> import os
>>
>>
>> def _expand_part(part, allow_sep_in_env_var):
>> # Expand environment variables in 'part'. If allow_sep_in_env_var is
>> # False, the resulting string cannot contain a path separator.
>
> Why would you ever set it to False?!? In realistic use, interpolating
> environment variables into paths is *expected* to be able to include
> path separators. $HOME might be "/home/foo" or "/root", temporary
> directories could be anywhere (and, on Windows, on any drive), etc,
> etc, etc. What is the use-case for a feature designed for paths that
> can't handle paths?
See Paul’s example, copied above. Maybe the code isn’t expecting it.
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/DPNBSYQOOPKB56WASNMRTKXG7ZQXXVBR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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 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.
>
> I'd like to see a Path.expandvars(), something like:
>
> --
>
> import os
>
>
> def _expand_part(part, allow_sep_in_env_var):
> # Expand environment variables in 'part'. If allow_sep_in_env_var is
> # False, the resulting string cannot contain a path separator.
Why would you ever set it to False?!? In realistic use, interpolating
environment variables into paths is *expected* to be able to include
path separators. $HOME might be "/home/foo" or "/root", temporary
directories could be anywhere (and, on Windows, on any drive), etc,
etc, etc. What is the use-case for a feature designed for paths that
can't handle paths?
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/GZMOYZCBLSXAO3LKL4IY3POSB3QF4472/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Missing expandvars equivalent in pathlib
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
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.
I'd like to see a Path.expandvars(), something like:
--
import os
def _expand_part(part, allow_sep_in_env_var):
# Expand environment variables in 'part'. If allow_sep_in_env_var is
# False, the resulting string cannot contain a path separator.
s = os.path.expandvars(part)
if s == part:
return part
if not allow_sep_in_env_var and os.path.sep in s:
raise ValueError(f"expanded variable {part!r} may not contain a
path separator")
return s
def expandvars(path, allow_sep_in_env_var=False):
return type(path)(
*list(_expand_part(part, allow_sep_in_env_var) for part in
path.parts)
)
from pathlib import Path
os.environ["USER"] = "foo"
os.environ["a"] = "d1/f1"
os.environ["b"] = "d1/f1"
print(f'{expandvars(Path("/usr/local/bin")) = }')
print(f'{expandvars(Path("/home/${USER}")) = }')
print(f'{expandvars(Path("${a}x${b}"), True) = }')
print(f'{expandvars(Path("${a}x${b}")) = }')
--
Output:
expandvars(Path("/usr/local/bin")) = PosixPath('/usr/local/bin')
expandvars(Path("/home/${USER}")) = PosixPath('/home/foo')
expandvars(Path("${a}x${b}"), True) = PosixPath('d1/f1xd1/f1')
Traceback (most recent call last):
File "expandpaths.py", line 26, in
print(f'{expandvars(Path("${a}x${b}")) = }')
File "expandpaths.py", line 14, in expandvars
return type(path)(*list(_expand_part(part, allow_sep_in_env_var)
for part in path.parts))
File "expandpaths.py", line 14, in
return type(path)(*list(_expand_part(part, allow_sep_in_env_var)
for part in path.parts))
File "expandpaths.py", line 10, in _expand_part
raise ValueError(f'expanded variable {part!r} may not contain a
path separator')
ValueError: expanded variable '${a}x${b}' may not contain a path separator
It would no doubt have to do something trickier with forward and back
slash detection after the expansion.
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/RQYAAGKGYAVG74X5QCFABKRJBJUL5P35/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
I'd be in favor of a nice syntax for named mapping unpacking.
But while we are at discussion - I'd point out it is "possible" (not easy)
with
current day syntax, by abusing the command "import" -
One can set appropriate import hooks that would enable
either for the current module, or maybe, in a context ("with") block
the use of import targeting a variable - so, the syntax
from mymap import key1, key2
can work.
Downside: it will be much slower than an assignment.
I have something similar working, but it is currently based
on monkey patching builtins.__import__ - upgrading it to properly
using the import machinery is on the roadmap.
On Fri, Feb 11, 2022 at 8:25 AM Matsuoka Takuo
wrote:
> 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 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/UC57YSWO7KLAXADXE5UCL3ILP4W7ZNMO/
Code of Conduct: http://python.org/psf/codeofconduct/
