RetroSearch Browse

Sat Apr 17 01:42:07 CEST 2010 · https://mail.python.org/pipermail/python-dev/2010-April/099470.html

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/

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-April/099470.html below:

[Python-Dev] Very Strange Argument Handling Behavior