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
> <tis...@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:tis...@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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
