_PyDict_GetItem_KnownHash should handle dk_lookup return value the same as PyDict_GetItem.

BTW, it seems PyDict_GetItem can call _PyDict_GetItem_KnownHash to remove duplicate code, if you like, maybe another issue?

diff -r 6acd2b575a3c Objects/dictobject.c
--- a/Objects/dictobject.c	Tue Sep 13 07:56:45 2016 +0300
+++ b/Objects/dictobject.c	Tue Sep 13 17:46:08 2016 +0800
@@ -1370,12 +1370,12 @@
         ix = (mp->ma_keys->dk_lookup)(mp, key, hash, &value_addr, NULL);
         /* ignore errors */
         PyErr_Restore(err_type, err_value, err_tb);
-        if (ix == DKIX_EMPTY)
+        if (ix < 0)
             return NULL;
     }
     else {
         ix = (mp->ma_keys->dk_lookup)(mp, key, hash, &value_addr, NULL);
-        if (ix == DKIX_EMPTY) {
+        if (ix < 0) {
             PyErr_Clear();
             return NULL;

Please create a patch file and attach it to the issue, so we can review it more easily.

Hmm, I thought this is trivial so I didn't. Now upload the file patch ;).

I understand the the code doesn't handle correctly lookup failures. Such failure is easy to trigger in pure Python using a custom __eq__() method for example. Can you please write an unit test for it?

_PyDict_GetItem_KnownHash is not invoked by any other dict methods. So to achieve it in pure Python level, we have to rely on others modules and objects such as OrderedDict, lru_cache. Is it a good idea to rely on those?

> _PyDict_GetItem_KnownHash is not invoked by any other dict methods.

Oh, I missed that. In this case, I suggest you to expose the function at Python level using the _testcapi module. And then use _testcapi._PyDict_GetItem_KnownHash() in test_dict.

It would be nice to have unit tests on _PyDict_GetItem_KnownHash(), this function starts to become important in Python.

How about let PyDict_GetItem call it? Just like the relationship of delitem and delitem_knownhash. You can see they share most codes. If we do that, it seems we can easily write a test(or there has already been a test) for it.

Xiang Zhang added the comment:
> How about let PyDict_GetItem call it?

PyDict_GetItem() is like the most important function in term of
performance for Python. If you want to touch it, you must benchmark
it.

I would prefer to keep it as it is.

> Just like the relationship of delitem and delitem_knownhash.

delitem is less important in term of performance, so I decided to
accept Naoki's change to merge duplicated code.

Update the patch with unittest.

If __eq__() raise an exception, _PyDict_GetItem_KnownHash() currently returns NULL and pass through the exception. To me, it looks like the correct behaviour.

With your patch, it looks like the _PyDict_GetItem_KnownHash() clears the __eq__() exception: return NULL with no exception set, as if the key is simply missing.

PyDict_GetItem() ignores *almost* all exceptions, but for bad reasons:

/* Note that, for historical reasons, PyDict_GetItem() suppresses all errors
 * that may occur (originally dicts supported only string keys, and exceptions
 * weren't possible).  (...) */

I would prefer to not ignore __eq__ exceptions, but pass them through.

To be clear: this is a behaviour change compared to Python 3.5 which works as PyDict_GetItem(), ignore *all* exceptions:

        ep = (mp->ma_keys->dk_lookup)(mp, key, hash, &value_addr);
        if (ep == NULL) {
            PyErr_Clear();
            return NULL;
        }

I consider that it's ok to change _PyDict_GetItem_KnownHash() behaviour because this function is private and only used 4 times in 250k lines of C code.

Would you be interested to write a different patch to pass through the exception?

Note: It seems like _count_elements() (Modules/_collectionsmodule.c) doesn't handle correctly such error.

Yes, ignoring exceptions is due to historical reasons. Although it's used rarely but I am still afraid changing it may break knowledge of devs that are already familiar with dict APIs. And what's more is there already exists two versions of getitem, one version with no exceptions and one version propagates exceptions (witherror), maybe we can also introduce a _PyDict_GetItem_KnownHashWithError?

Xiang Zhang: "I am still afraid changing it may break knowledge of
devs that are already familiar with dict APIs"

Come on, the function is only called 4 times in the whole code base,
and the function is private. Private means that we are free to break
its behaviour anytime, it's part of the contract.

Hah, Okay. I'll make the corresponding change then.

Victor, v3 now applies your suggestion.

Actually ignoring exceptions in _PyDict_GetItem_KnownHash causes a subtle difference between Python and C implementations. Making _PyDict_GetItem_KnownHash not ignoring exceptions looks right thing.

But dict_merge expects that _PyDict_GetItem_KnownHash don't raise an exception.

dict_merge was altered after the patch. I make it ignore explicitly the error now, to not affect former behaviour.

Serhiy, I apply your suggestion to use _PyLong_AsByteArray for Py_hash_t, but I am not familiar with the API. It needs a review.

If _PyDict_GetItem_KnownHash() returns an error, it is very likely that following insertdict() with same key will return an error. I would prefer to return an error right after _PyDict_GetItem_KnownHash() is failed. This would look more straightforward.

> If _PyDict_GetItem_KnownHash() returns an error, it is very likely that following insertdict() with same key will return an error.

Make sense.

LGTM. I'll commit the patch soon if there are no comments from other core developers.

LGTM.

New changeset d06a6b0fd992 by Serhiy Storchaka in branch '3.6':
Issue #28123: _PyDict_GetItem_KnownHash() now can raise an exception as
https://hg.python.org/cpython/rev/d06a6b0fd992

New changeset 805467de22fc by Serhiy Storchaka in branch 'default':
Issue #28123: _PyDict_GetItem_KnownHash() now can raise an exception as
https://hg.python.org/cpython/rev/805467de22fc

Sorry, I didn't have time to review this issue :-(

Thanks Xiang and Serhiy for fixing the issue! I prefer the new API (don't
ignore the error).