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

Michael Foord fuzzyman at voidspace.org.uk
Sat Apr 17 01:42:07 CEST 2010

On 17/04/2010 01:38, Steve Holden wrote:

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', 'theother': 'Steve', 'that': 'Raymond'} Or would we? Nobody is proposing barring that.

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 they are completely different operations.

Michael

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

-- http://www.ironpythoninaction.com/

More information about the Python-Dev mailing list