Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
On Wed, May 15, 2019 at 1:37 AM Anders Hovmöller wrote: > > > On 15 May 2019, at 03:07, Robert Vanden Eynde wrote: > > > > Currently if one wants to provide positional arguments after keyword > > arguments, it's not possible, one must begin with positional arguments [1] > > or use keyword arguments [2] : > > I'm my opinion the goal should be that there is no such thing as positional > only arguments in python. It's just a bad idea. No r al arguments that can be > both positional or keyword at the call site, or keyword only. Those are good > and make sense. Adding a third option is just added complexity. That's not a realistic goal; there are some use cases, including in CPython builtins, that cannot be accomplished without positional-only arguments. For example, the current behavior of the `dict` constructor is to accept both certain iterables as a positional-only argument and/or keyword arguments from which a dict can be created. If the iterable argument was not positional-only, then it would be forced to consume a keyword (even if the caller passes it as a positional argument), meaning that that keyword could never be included in **kwargs and could not become a dict key via keyword arguments. Additionally, PEP 570 [1], which will add syntax for positional-only parameters in Python functions, was accepted by Guido last month. [1] https://www.python.org/dev/peps/pep-0570/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
Le mer. 15 mai 2019 à 07:37, Anders Hovmöller a écrit : > > > > On 15 May 2019, at 03:07, Robert Vanden Eynde > wrote: > > > > Currently if one wants to provide positional arguments after keyword > arguments, it's not possible, one must begin with positional arguments [1] > or use keyword arguments [2] : > > In my opinion the goal should be that there is no such thing as positional > only arguments in python. It's just a bad idea. No r al arguments that can > be both positional or keyword at the call site, or keyword only. Those are > good and make sense. Adding a third option is just added complexity. > But what if on the call side the user wants to specify y before x but the definition side wanted "positional only args" for performance reason ? On another note, there's no way to specify "positional only arguments" in "pure python" using a syntax used in the documentation like "def f(x, y, /)" (but def f(*args) will do the trick). > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
> On 15 May 2019, at 03:07, Robert Vanden Eynde wrote: > > Currently if one wants to provide positional arguments after keyword > arguments, it's not possible, one must begin with positional arguments [1] or > use keyword arguments [2] : I'm my opinion the goal should be that there is no such thing as positional only arguments in python. It's just a bad idea. No r al arguments that can be both positional or keyword at the call site, or keyword only. Those are good and make sense. Adding a third option is just added complexity. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Passing positional arguments as keyword arguments (to provide function arguments out of order)
Currently if one wants to provide positional arguments after keyword arguments, it's not possible, one must begin with positional arguments [1] or use keyword arguments [2] : ``` def f(x, *, long_name='foo'): return ... f(2, long_name='bar') # [1] f(long_name='bar', x=2) # [2] ``` The problem is that it's not always possible to do so because some functions cannot have keyword arguments (because they call a C function) like math.hypot : ``` import math math.hypot(y=5, x=2) # TypeError ``` A solution is to use partial. ``` from functools import partial partial(f, long_name='bar')(2) ``` But that begins to be "functional programming style" and that doesn't solve the case where one would like to change the order of (I created funcoperators.elipartial for that reason) : ``` from funcoperators import elipartial elipartial(math.hypot, ..., 5)(2) ``` Of course one could create a tuple and a dict they call f(*a, **k) but cannot be used inside an expression. ``` k = dict(long_name='bar') a = (2, ) f(*a, **k) ``` So what would be a good new syntax for that or workaround I didn't think of ? ``` f(**dict(long_name='bar'), *(2, )) f(long_name='bar', 0=2) math.hypot(0=5, 1=2) f(long_name='bar', args[0]=2) math.hypot(args[0]=5, args[1]=2) ... ``` I don't know if such an idea has been asked before (I don't know how to formulate it). robertvandeneynde.be ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets
On 5/14/19, Steven D'Aprano wrote: > > On posix systems, you should be able to use chattr +i to make the file > immutable, so that the attacker cannot remove or replace it. Minor point of clarification. File attributes, and APIs to access them, are not in the POSIX standard. chattr is a Linux command that wraps the filesystem IOCTLs for getting and setting file attributes. There's no chattr system call, so thus far it's not supported in Python's os module. BSD and macOS have chflags, which supports both system- and user-immutable file attributes. Python supports it as os.chflags. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets
On Tue, May 14, 2019 at 10:26:28AM +0300, Serge Matveenko wrote: > How about introducing `force=False` argument to > `pathlib.Path.symlink_to` method? > It looks like a good place for this as `pathlib` is actually the place > where higher-level things to operate on paths live already I don't think we can say pathlib is the place for higher-level operations. It isn't what the os docs say: https://docs.python.org/3/library/os.html it explicitly says shutils is for higher-level path operations. The beauty of shutil is that it can operate on pathnames whether they are strings, bytes or Path objects, and doesn't force you to use one or the other. Aside: I'm not sure how much progress has been made on making Path objects fully usable by shutil. There's this open issue: https://bugs.python.org/issue30235 so I think progress is being made but may not be complete. -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets
> On 14 May 2019, at 14:13, Steven D'Aprano wrote: > >> On Tue, May 14, 2019 at 10:37:57AM +0300, Serge Matveenko wrote: >> >> My point was that in case of `os.symlink` vs `shutil.symlink` it is >> not obvious how they are different even taking into account their >> namespaces. > > Okay, but that's not what you said. I can't respond to what you meant to > say in hindsight, only what you actually said at the time: Sure you can. By responding to the mail where he clarifies what he meant but failed to get across the first time. Pointing out again that he failed to communicate to you like he tried the first time around is not very constructive. It would be better if you could let that go and just move forward. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets
On Tue, May 14, 2019 at 10:37:57AM +0300, Serge Matveenko wrote: > My point was that in case of `os.symlink` vs `shutil.symlink` it is > not obvious how they are different even taking into account their > namespaces. Okay, but that's not what you said. I can't respond to what you meant to say in hindsight, only what you actually said at the time: I SEE AND EXPECT no obvious difference between `os.symlink` and `shutil.symlink`. [emphasis added] Can we agree that the difference between os.symlink and shutils.symlink is visible (they are in different namespaces) and we should expect that they are different for that reason? If we *can't* agree on that point, if you truly see no difference between (for example) os.open bz2.open gzip.open io.open etc. then I don't think we will ever reach agreement. Our expectations are just too different. I am happy to agree with you that the difference in qualified names is not enough to tell *how they differ*, only that they likely do differ. To know how they differ, one needs to read the docs, or ask. I don't see this as a problem. > In the case `os.remove` vs `list.remove` the difference is obvious as > namespaces clearly represent different subjects. On the other hand, it > is not that easy to guess the developer intent comparing `os` and > `shutil` subjects. There's no need to guess. The documentation is clear: https://docs.python.org/3/library/os.html This module provides a portable way of using operating system dependent functionality. [...] and for high-level file and directory handling see the shutil module. So I guess the question comes down to whether we believe that safely replacing an existing file with a symlink is low-level OS functionality or high-level functionality. Here are three pieces of evidence to help decide: (1) The Windows mklink command has no option to overwrite files: that suggests that on Windows, "make a syslink and overwrite the destination" is not low-level OS functionality. (2) The Linux symlink system call does not override files either: man symlink This also argues against putting this in the os module. (3) The ``ln`` shell command does have an option to force overwriting. This argues in favour of treating it as a shell command and putting it in shutils. In the rest of your email, you asked a bunch of questions. I assume that you intend them as rhetorical questions, but I don't know why you included them since they don't seem relevant. We could ask precisely the same questions no matter what we called this proposed function or where we put it. -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] [SPAM?] Re: shutil.symlink to allow non-race replacement of existing link targets
On 5/14/19 6:55 AM, Rhodri James wrote: > On 14/05/2019 05:50, Anders Hovmöller wrote: >> >> >>> On 14 May 2019, at 04:24, Steven D'Aprano wrote: >>> >>> *wink*. Function names are mnemonics, not documentation. >> >> Certainly not with that attitude. But it easily could be. Maybe you >> would be fine with a language where all function names are just hex >> values? *wink* (yes I think this was rude but that's my point). > > I'm an assembler programmer. Function names *are* just hex values :-) > > Actually, even to an assembler programmer, most Function names are symbolic labels. Yes, you CAN write a call to an absolute (or relative) memory address, but that is unusual unless you are writing an in memory patch to an already established program. Do you really write something like: call 0x32453 very often? -- Richard Damon ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets
13.05.19 12:38, Tom Hale пише: As suggested by Toshio Kuratomi at https://bugs.python.org/issue36656, I am raising this here for inclusion in the shutil module. Mimicking POSIX, os.symlink() will raise FileExistsError if the link name to be created already exists. A common use case is overwriting an existing file (often a symlink) with a symlink. Naively, one would delete the file named link_name file if it exists, then call symlink(). This "solution" is already 3 lines of code, and without exception handling it introduces the race condition of a file named link_name being created between unlink and symlink. Depending on the functionality required, I suggest: * os.symlink() - the new link name is expected to NOT exist * shutil.symlink() - the new symlink replaces an existing file Sorry, but I do not understand what problem do you try to solve. If somebody can create a file named link_name between unlink and symlink, he can also remove and create a file named link_name after symlink. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] [SPAM?] (meta) Mailman cleartext passwords
On 5/14/19 5:35 AM, Tom Hale wrote: > When I signed up, I got an email with subject: > > Welcome to the "Python-ideas" mailing list > > It included the text: > > == > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe without confirmation. It is: > > my-cleartext-password > > == > > This has bugged me about Mailman in the past... luckily I used a > low-tier password for this (I know, I should use a unique password). > > But some users will use a password which is valuable to them. > > Should this "feature" be turned off for new subscribers? > As someone who runs a Mailman list for non-technical users, I will say that this feature also bothers me a bit, but the problems that come by disabling it are worse. First, there is a notice right on the signup form that this will happen, so users have been warned. If they are reusing passwords, the fact that the list has a copy of the password and emails it out is likely NOT among the highest risks to their security, and perhaps the perceived breach might get them to change. The emailing of the password in plain text isn't that big of a security issue for most people. Yes, if someone is reading your email you have a problem, but that is not the risk for most people, and if they can do that, then likely you are already in a security compromised situation. As explained on the Mailman site, the possible risk to a user of having their Mailman subscription 'hacked' is small, the biggest danger is you could be unsubscribed. Mailman 3 has changed the behavior and uses the more standard password reset mechanism than the password being sent. In the not to distant future, hopefully Mailman 3 will be in a state where migrating a Mailman 2 list to it will be a reasonable course of action. I also find it amazing how many people forget what email address they signed up with, so for a list that requires one to be subscribed to submit messages, this can be important, so the periodic sending of the subscription details is important, as otherwise someone needs to search through the subscribed database to figure out how they were subscribed. (I would suggest that most lists want the subscribed list to be accessible only by a few trusted individuals to avoid scraping for spamming.) -- Richard Damon ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] (meta) Mailman list searching
On Tue, May 14, 2019 at 04:46:48PM +0700, Tom Hale wrote: > How do I search this list's archives? With Google: site:mail.python.org the_search_term Google nearly always has better results than the search features of individual websites. Stefan Krah ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] (meta) Mailman list searching
On 14/5/19 4:46 pm, Tom Hale wrote: How do I search this list's archives? Inspiration struck: Google for: site:https://mail.python.org/pipermail/python-ideas/ search terms -- Tom Hale ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] (meta) Mailman cleartext passwords
When I signed up, I got an email with subject: Welcome to the "Python-ideas" mailing list It included the text: == You must know your password to change your options (including changing the password, itself) or to unsubscribe without confirmation. It is: my-cleartext-password == This has bugged me about Mailman in the past... luckily I used a low-tier password for this (I know, I should use a unique password). But some users will use a password which is valuable to them. Should this "feature" be turned off for new subscribers? -- Tom Hale ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] (meta) Broken link to gmane.org archive of python-ideas
On 14/5/19 10:53 am, Brett Cannon wrote: Bugs about the website should be reported to https://github.com/python/pythondotorg . Thanks, reported at: https://github.com/python/pythondotorg/issues/1435 -- Tom Hale ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets
On 5/14/19, Serge Matveenko wrote: > > My point was that in case of `os.symlink` vs `shutil.symlink` it is > not obvious how they are different even taking into account their > namespaces. I prefer to reserve POSIX system call names if possible, unless it's a generic name such as "open" or "close". Note that there's also the possibility of extending pathlib's `symlink_to` method. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets
On Tue, May 14, 2019 at 4:34 AM Steven D'Aprano wrote: > You "see ... no obvious difference" between two functions that live in > completely different modules? > > > > The bottom line is that it is completely normal and not uncommon for > functions to be distinguished by the namespace they are found in. It is > both unreasonable and unnecessary to force objects in different > namespaces to have unique names. There is no need to explain basic things to me. Thank you very much indeed! My point was that in case of `os.symlink` vs `shutil.symlink` it is not obvious how they are different even taking into account their namespaces. In the case `os.remove` vs `list.remove` the difference is obvious as namespaces clearly represent different subjects. On the other hand, it is not that easy to guess the developer intent comparing `os` and `shutil` subjects. Why there are two different implementations? Which one should I use? While I don't need "force" functionality at the moment is it ok to use the one from `os` package or I would need that in the future? Is it worth just stick with the one from `shutil` and forget that `os.symlink` exists at all? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] shutil.symlink to allow non-race replacement of existing link targets
On Tue, May 14, 2019 at 6:19 AM Steven D'Aprano wrote: > The problem is a lack of a symlink function that safely overwrites an > existing file or symlink. We're just bike-shedding over its spelling > and where it lives: > > - modify os.symlink and give it a "force" parameter > - add a new function into shutils How about introducing `force=False` argument to `pathlib.Path.symlink_to` method? It looks like a good place for this as `pathlib` is actually the place where higher-level things to operate on paths live already and this method already has a different name and a slightly different signature. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
