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/
_______________________________________________
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
