[Python-Dev] arguments policy: **kwargs.pop()

[Christian Tismer]

Ah, now I see it.

For some reason, I forgot that the dict is always newly created.
That was really wrong thinking. Sorry!

On 11/04/14 05:47, Guido van Rossum wrote:
> I'm not sure what you're worried about here. Modifying kwds doesn't
> actually modify the dict that was passed in. So are you just talking about
> the style issue? Or would you also object to this:
> 
> def foo(x=1):
>     x += 1
> 

No, this is ok, although I personally tend not to modify args.

No, it was just my temporary forgetting that the star
args/kwds are always in a new container, and the whole reasoning chain
was pointless, therefore.

Thanks and cheers - Chris


> On Thu, Apr 10, 2014 at 10:12 PM, Christian Tismer <tismer at stackless.com>wrote:
> 
>> Hi guys,
>>
>> I tried to find advice for hours, but failed so fer, so here is my
>> question:
>>
>> Whenever I think to adopt a new module that does a good job, I always
>> can't stand the temptation to look at the coding style and certain
>> principles.
>>
>> Then I rather often see things like this:
>>
>> class someclass(object):
>>     # note that there is no comment about argument destruction...
>>
>>     def __init__(self, **kwargs):
>>         first_arg = kwargs.pop('option_1', somedefault)
>>         ...
>>         nth_arg = kwargs.pop('option_n', somedefault')
>>         ...
>>
>> That is:
>> There are arguments "consumed" rigorously by the __init__ of a class,
>> although it would be equivalent to use kwargs.get(..., ...).
>>
>> Happened to me again, today and blocked me completely, since I don't
>> know if I saw bad programming style or if I'm mislead.
>>
>> I agree there are valid cases when if makes sense to filter out some
>> arguments
>> that a subsequently called super() might not be able to handle.
>> Bu even then, I would probably have a copy and make the filtering more
>> explicit.
>>
>> But most of the time, there is no reason for using this pattern, and there
>> is also no comment stating that the argument dict is modified by the callee
>> for no good reason.
>>
>> I always used the policy that arguments are never changed by a function,
>> unless explicitly stated.
>> But since I see this pattern quite frequently, I wanted to ask if I am
>> right by
>> thinking this way, or if the general policy is more like "arguments may be
>> destroyed by default".
>>
>> What do you think? Is this bad style and should be noticed somewhere,
>> or is the caller supposed to protect the arguments, or are my worries
>> useless?
>>
>> Thanks & cheers -- Chris
>>


-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/