[Python-ideas] Keyword only argument on function call
Jacco van Dorp
j.van.dorp at deonet.nl
Tue Sep 11 02:54:33 EDT 2018
Op di 11 sep. 2018 om 06:48 schreef Steve Barnes <gadgetsteve at 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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180911/7f22b492/attachment-0001.html>
More information about the Python-ideas
mailing list