My 3 cents: 1. My most objective objection against the f(*, foo, bar, baz) syntax is that it looks like positional arguments, and the syntactic marker * which dissuades you of that can be arbitrarily far apart from the keyword.
2. The syntax f(=foo, =bar, =baz) at least solves that problem. Otherwise I find it quite ugly with the unbalanced = but that is obviously more subjective. 3. I still am not convinced it is needed at all. IMHO, if your code is filled with f(foo=foo, bar=bar, baz=baz) then perhaps Python is telling you that foo, bar and baz want to become fields in a new object which you should pass around. 4. (Bonus cent) Somewhat tongue-in-cheek I offer the following Vim mapping for those who find themselves typing longword=longword all the time. :inoremap <F8> =<Esc>hyiwt=lpa Now you can just do longword<F8>. Stephan Op di 11 sep. 2018 om 08:55 schreef Jacco van Dorp <j.van.d...@deonet.nl>: > > > Op di 11 sep. 2018 om 06:48 schreef Steve Barnes <gadgetst...@live.co.uk>: > >> >> >> On 10/09/2018 22:00, Ethan Furman wrote: >> > On 09/10/2018 12:52 PM, Chris Barker via Python-ideas wrote: >> > >> >> I've spent this whole thread thinking: "who in the world is writing >> >> code with a lot of spam=spam arguments? If you are transferring that >> >> much state in a function call, maybe you should have a class that >> >> holds that state? Or pass in a **kwargs dict? >> > >> >> So still looking for a compelling use-case >> > >> > In my day job I spend a lot of time writing/customizing modules for a >> > framework called OpenERP (now Odoo*). Those modules are all >> subclasses, >> > and most work will require updating at least a couple parent metheds -- >> > so most calls look something like: >> > >> > def a_method(self, cr, uid, ids, values, context=None): >> > ... >> > super(self, parent).a_method(cr, uid, ids, values, context=context) >> > >> > Not a perfect example as these can all be positional, but it's the type >> > of code where this syntax would shine. >> > >> > I think, however, that we shouldn't worry about a lead * to activate >> it, >> > just use a leading '=' and let it show up anywhere and it follows the >> > same semantics/restrictions as current positional vs keyword args: >> > >> > def example(filename, mode, spin, color, charge, orientation): >> > pass >> > >> > example('a name', 'ro', =spin, =color, charge=last, =orientation) >> > >> > So +0 with the above proposal. >> > >> > -- >> > ~Ethan~ >> > _______________________________________________ >> > Python-ideas mailing list >> > Python-ideas@python.org >> > https://mail.python.org/mailman/listinfo/python-ideas >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> >> Couldn't just about all of the use cases mentioned so far be met in >> quite a neat manner by providing access to a method, or dictionary, >> called __params__ which would give access, as a dictionary, to the >> parameters as supplied in the call, (or filled in by the defaults). >> >> If this was accessible externally, as fn.__defaults__ is then examples >> such as: >> >> > def a_method(self, cr, uid, ids, values, context=None): >> > ... >> > super(self, parent).a_method(cr, uid, ids, values, >> context=context) >> >> would become: >> >> >> def a_method(self, cr, uid, ids, values, context=None): >> ... >> params = {k:v for k,v in __params__ if k in parent.a_method.keys()} >> # Possibly add some additional entries here! >> super(self, parent).a_method(**params) > > > So...deep black magic ? That's what this looks like. Having =spam for > same-named kwargs sounds easier to comprehend for new people than a > __magic__ object you can only access in function bodies and will give > headaches if you have to write decorators: > > def other_function_defaults(*args, **kwargs): > outer_params = __params__.copy() > def deco(func): > def inner(self, yo_momma): > return func(self, **outer_params, **__params__) # overwrite with > specifically provided arguments > return deco > > > I think that magic objects like that aren't really pythonic - if it were, > "self" would be the same kind of magic, instead of us having to name it on > every function call (A decision im really a fan of, tbh) > _______________________________________________ > 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 mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/