Title: TypeError: unhashable type: 'instancemethod'
Type: behavior Stage: resolved
Components: Versions: Python 3.8, Python 3.7, Python 3.6, Python 3.5
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: christian.heimes, r.david.murray, siming85
Priority: normal Keywords:

Created on 2018-04-30 20:39 by siming85, last changed 2018-05-01 16:42 by r.david.murray. This issue is now closed.

Messages (6)
msg315964 - (view) Author: Siming Yuan (siming85) * Date: 2018-04-30 20:39
in Python 3.5 it the pprint.PrettyPrinter mechanism got an overhaul, relying on PrettyPrinter._dispatch dict-lookup based on obj.__repr__ type.

This breaks any Cythonized 3rd party libraries that used to be pretty-printable in Python3.4.

<instancemethod __repr__ at 0x10cf2a618>

since instancemethod_hash function has been commented out:

oddly the behavior is different between Linux and Mac.

The same object in Linux returns cyfunction, and is hashable,
where as under the same CPython version in Mac, it returns instancemethod, rendering it unhashable.
(based on Cython 0.27.3)

note that this isn't exactly something related directly to the implementation of Cython.

the old logic in Python <3.4 pprint was not pretty (pun not intended), but relied solely on type checking,
where as the new implementation depends on hashing, which introduces this bug.
msg315975 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2018-04-30 23:31
The non-hashable case should be handled by a default function, I would think.  It should be fairly straightforward to come up with a reproducer that does not involve cython, which I think would be the first step.
msg315979 - (view) Author: Siming Yuan (siming85) * Date: 2018-05-01 03:17
having a tough time trying to reproduce this issue in pure python.

any clue as to how to create a __repr__ that's unhashable?

class UnhashableRepr(dict):
    __repr__ = _testcapi.instancemethod(dict.__repr__)

doesn't work because that turns into a <slot wrapper '__repr__' of 'dict' objects> which becomes hashable.

i'd love to provide a patch, seems trivial to fix, but wouldn't want to do so without some tests.
msg315996 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2018-05-01 13:59
Ah, in the absence of a traceback I think I misunderstood the problem (I failed to actually look at the code :)

Given what you say about the slotwrapper, I'm not sure, but I'm guessing that that means cython isn't using the PyInstanceMethod_Type as intended.  That doesn't mean it can't be fixed (though if true it makes it less likely that we'll fix it, unfortunately), but you'll have to figure out what the difference is between how it is used by cython and cpython.  I've nosied Christian, maybe he'll remember why the hash is commented out.
msg316003 - (view) Author: Siming Yuan (siming85) * Date: 2018-05-01 15:57
i just discovered cython v0.28 no longer creates instancemethod, so this bug should technically no longer show up after upgrading cython.
(related cython bug

so the question remains - is it a good idea to assume all type(obj).__repr__ is hashable?

if so, we can close this bug.
msg316004 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2018-05-01 16:42
Functions/methods should be immutable, so yes, I think it is a safe assumption that they should be hashable, and a bug if they are not.  I seem to vaguely recall that there is some other part of the cpython machinery that depend on being able to test function/method equality and assumes that they are immutable, which implies they should be hashable.

I'll close this; Christian can reopen it if he thinks there is an actual bug lurking here.
Date User Action Args
2018-05-01 16:42:17r.david.murraysetstatus: open -> closed
type: crash -> behavior
messages: + msg316004

resolution: third party
stage: resolved
2018-05-01 15:57:50siming85setmessages: + msg316003
2018-05-01 13:59:29r.david.murraysetnosy: + christian.heimes
messages: + msg315996
2018-05-01 03:17:25siming85setmessages: + msg315979
2018-04-30 23:31:04r.david.murraysetnosy: + r.david.murray
messages: + msg315975
2018-04-30 20:39:51siming85create