Raymond Hettinger wrote: > > On Apr 16, 2010, at 2:42 PM, Daniel Stutzbach wrote: >> >> IIRC, there's a performance hack in dictobject.c that keeps track of >> whether all of the keys are strings or not. The hack is designed so >> that lookup operations can call the string compare/hash functions >> directly if possible, rather than going through the slower PyObject_ >> functions. >> >> Consequently, validating **kwds should be cheap. >> > Good thinking. > > That would definitely be better than scanning the full dict on every call. > 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", the_other="Steve") {'this': 'Guido', 1: 'dummy', 'the_other': '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? 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? 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/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com