[Python-Dev] Very Strange Argument Handling Behavior
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", the_other="Steve")
>>>>
> {'this': 'Guido', 1: 'dummy', 'the_other': '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