This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients methane, rhettinger, serhiy.storchaka, vstinner
Date 2017-01-17.11:54:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1484654096.62.0.464246999195.issue29295@psf.upfronthosting.co.za>
In-reply-to
Content
It looks to me that PyDict_GetItemString(), PyObject_GetAttrString(), etc are mainly for backward compatibility and for using in performance non-critical code. Performance critical code caches string objects.

The only code that heavily used PyDict_GetItemString() was parsing keyword arguments in PyArg_ParseTupleAndKeywords(). But this API was replaced with more efficient _PyArg_ParseTupleAndKeywordsFast() and _PyArg_ParseStackAndKeywords() for internal use. I think something similar will be exposed as public API when it become enough mature. Issue29029 made PyArg_ParseTupleAndKeywords() much less using PyDict_GetItemString().

PyDict_GetItemString() can be used with non-ASCII C strings. They are decoded with UTF-8. The patch works incorrectly in this case.

I afraid that adding more and more specialized code in Objects/dictobject.c can slow down other functions in this file. And this makes the maintenance harder.
History
Date User Action Args
2017-01-17 11:54:56serhiy.storchakasetrecipients: + serhiy.storchaka, rhettinger, vstinner, methane
2017-01-17 11:54:56serhiy.storchakasetmessageid: <1484654096.62.0.464246999195.issue29295@psf.upfronthosting.co.za>
2017-01-17 11:54:56serhiy.storchakalinkissue29295 messages
2017-01-17 11:54:56serhiy.storchakacreate