[Python-Dev] Very Strange Argument Handling Behavior (original) (raw)

Steve Holden steve at holdenweb.com
Sat Apr 17 17:24:42 CEST 2010

Guido van Rossum wrote:

On Fri, Apr 16, 2010 at 4:38 PM, Steve Holden <steve at holdenweb.com> wrote:

I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)

def f(**kwargs): ... kwargs[1] = "dummy" ... print(kwargs) ... f(this="Guido", that="Raymond", theother="Steve") {'this': 'Guido', 1: 'dummy', 'theother': 'Steve', 'that': 'Raymond'} Or would we? If it's OK to mutate kwargs inside the function to contain a non-string key, why isn't it OK to pass a non-string key in? Because Python promises that the object the callee sees as 'kwargs' is "just a dict". But the requirement for what the caller passes in is different: it must pass in a dict whose keys represent argument names. If you want an API where you can pass in an arbitrary dict to be received unchanged, don't use **kw. Remember that the caller can independently decide whether or not to use the **kw notation -- there is no implied correspondence between the caller's use of **kw and the callee's use of it. Note this example: def f(a, b, **k): print(a, b, k) d = {'a': 1, 'b': 2, 'c': 3} f(**d) This will print 1 2 {'c': 3} Note that the k received by f is not the same as the d passed in! (And yet d of course is not modified by the operation.) Good point, and one I hadn't thought of. I was blithely assuming that the dict seen by the called function was always what was passed as the dict argument.

I understand that it couldn't be generated using keyword argument syntax, but I don't see why we discriminate against f(**dict(...)) to limit it to what could be generated using keyword argument syntax. Is this such a big deal? Is portability of code to Jython, IronPython, PyPy a big deal? According to a slide you recently posted to the PSF board list, it is. And I haven't changed my mind since. Thanks for the comprehensive response.

regards Steve

Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

More information about the Python-Dev mailing list