On Jul 27, 2019, at 08:04, Anders Hovmöller <boxed@killingar.net> wrote:
On 27 Jul 2019, at 14:47, Dominik Vilsmeier <dominik.vilsmeier@gmx.de> wrote:
currently, regarding positional arguments, `partial` gives us the option to partialize functions from the left. There's been some interest about partializing functions from the right instead (e.g. [SO post, 9k views, 39 upvotes](https://stackoverflow.com/q/7811247/3767239)), especially w.r.t. the various `str` methods.
Do you have other examples? That (and most likely similar) examples are just that the standard library contains methods and functions that could be fixed to accept keyword arguments. This would be less confusing and more coherent.
Many of the compelling examples for PEP 570 are good examples here. The following are all impossible intentionally, and for different reasons: skipper = partial(range, step=n) powbase = partial(pow, mod=base) clscheck = partial(isinstance, class_or_tuple=cls) Plus, there’s also one very general example: anything that semantically has to take *args can’t be changed to use keywords: partial(format, 2=x) partial(map, 1=x, 2=y) partial(executor.submit, 1=arg) And similarly for itertools.product, min/max, and everything that acts as a proxy like submit. Also, even for cases like the OP’s where there’s no semantics reason the argument couldn’t have a keyword, there may still be other reasons. When argclinic was added in PEP 436, it was specifically argued that it shouldn’t be used as an opportunity to phase out positional-only params, in part because for many functions the performance cost of keyword processing outweighs the uncommon potential use of the keywords; IIRC, the OP’s specific method was even one of the core examples. And, as PEP 570 points out, METH_FASTCALL makes that potentially true for pure Python functions as well, to the extent that some other stdlib functions might actually want to lose their keyword args. All that being said, this proposal seems like something that could easily be put on PyPI to see how much uptake it gets, instead of put immediately into the stdlib. I think people will find it useful. But maybe, say, funcy/toolz/etc. will borrow the idea and it’ll turn out that almost everyone who wants it already wants one of those libs anyway. Or maybe the bikeshedding potential will be higher than expected, and a variety of different modules that all handle the placeholders differently will compete, and it’ll turn out that everyone loves some different design that allows both single-arg and multi-arg placeholders