The following is a story about the Python 3.3 built-in function hash ().
KaoriYa version of Vim now supports Python 3.3, so jedi-vim does not support 3.3. While trying to trick jedi-vim) into running, I noticed that jedi used by jedi-vim was failing to open the cache file I did.
The problem is generating the cache filename
jedi/cache.py
def _get_hashed_path(self, path):
return self._get_path('%s_%s.pkl' % (self.py_version, hash(path)))
This is because the result of hash () is non-deterministic, to be exact, the determinacy of hash () is closed in the process.
Let's actually check it.
$ python3.3
...
>>> hash("spam")
-2615809667644326338
>>> hash("spam")
-2615809667644326338
>>>
$ python3.3
...
>>> hash("spam")
5272786964549530217
>>> hash("spam")
5272786964549530217
>>>
You can see that the return value of hash (" spam ") changes from process to process.
The jedi error only occurred in Python 3.3 in Python 3.3 [hashes were randomized for security reasons](http://docs.python.jp/3.3/whatsnew/3.3.html# builtin-functions-and-types).
For the time being, speed was not necessary, so if the Python version is 3.3 or higher, use hashlib.md5 (). I tried to fix it.
As an aside, jedi is still not compatible with Python 3.3 because 3.3 introduced a new namespace package mechanism and imp.find_module (). The main reason is that imp.html # imp.find_module) has been deprecated.
At hand, use importlib.find_loader () to return imp.find \ _module () "like" results I wrote a function to deceive it, but please refrain from publishing it because it is a temporary code. m (\ _ \ _) m
Recommended Posts