On Jul 27, 2019, at 08:04, Anders Hovmöller <bo...@killingar.net> wrote:
>
>> On 27 Jul 2019, at 14:47, Dominik Vilsmeier <dominik.vilsme...@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
_______________________________________________
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/AAA32XZ3O7HNESRDQ437OS35MPAFUPTT/
Code of Conduct: http://python.org/psf/codeofconduct/
