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

Steve Holden steve at holdenweb.com
Sat Apr 17 01:38:44 CEST 2010

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", theother="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/

More information about the Python-Dev mailing list