<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Op di 11 sep. 2018 om 06:48 schreef Steve Barnes <<a href="mailto:gadgetsteve@live.co.uk">gadgetsteve@live.co.uk</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 10/09/2018 22:00, Ethan Furman wrote:<br>
> On 09/10/2018 12:52 PM, Chris Barker via Python-ideas wrote:<br>
> <br>
>> I've spent this whole thread thinking: "who in the world is writing <br>
>> code with a lot of spam=spam arguments? If you are transferring that <br>
>> much state in a function call, maybe you should have a class that <br>
>> holds that state? Or pass in a **kwargs dict?<br>
> <br>
>> So still looking for a compelling use-case<br>
> <br>
> In my day job I spend a lot of time writing/customizing modules for a <br>
> framework called OpenERP (now Odoo*).  Those modules are all subclasses, <br>
> and most work will require updating at least a couple parent metheds -- <br>
> so most calls look something like:<br>
> <br>
>    def a_method(self, cr, uid, ids, values, context=None):<br>
>      ...<br>
>      super(self, parent).a_method(cr, uid, ids, values, context=context)<br>
> <br>
> Not a perfect example as these can all be positional, but it's the type <br>
> of code where this syntax would shine.<br>
> <br>
> I think, however, that we shouldn't worry about a lead * to activate it, <br>
> just use a leading '=' and let it show up anywhere and it follows the <br>
> same semantics/restrictions as current positional vs keyword args:<br>
> <br>
>    def example(filename, mode, spin, color, charge, orientation):<br>
>        pass<br>
> <br>
>    example('a name', 'ro', =spin, =color, charge=last, =orientation)<br>
> <br>
> So +0 with the above proposal.<br>
> <br>
> -- <br>
> ~Ethan~<br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
<br>
Couldn't just about all of the use cases mentioned so far be met in <br>
quite a neat manner by providing access to a method, or dictionary, <br>
called __params__ which would give access, as a dictionary, to the <br>
parameters as supplied in the call, (or filled in by the defaults).<br>
<br>
If this was accessible externally, as fn.__defaults__ is then examples <br>
such as:<br>
<br>
 >    def a_method(self, cr, uid, ids, values, context=None):<br>
 >      ...<br>
 >      super(self, parent).a_method(cr, uid, ids, values, context=context)<br>
<br>
would become:<br>
<br>
<br>
     def a_method(self, cr, uid, ids, values, context=None):<br>
       ...<br>
       params = {k:v for k,v in __params__ if k in parent.a_method.keys()}<br>
       # Possibly add some additional entries here!<br>
       super(self, parent).a_method(**params)</blockquote><div><br></div><div>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:</div><div><br></div><div>def other_function_defaults(*args, **kwargs):</div><div>    outer_params = __params__.copy()</div><div>    def deco(func):</div><div>        def inner(self, yo_momma):</div><div>        return func(self, **outer_params, **__params__)  # overwrite with specifically provided arguments</div><div>    return deco</div><div><br></div><div><br></div><div>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)</div></div></div>