STINNER Victor added the comment: Oh yes, Antoine also asked if Python/ and Include/ directories are the right place for hashtable.c and hashtable.h files. _Py_slist and _Py_hashtable are only used in Modules/_tracemalloc.c yet.
It was discussed to reuse _Py_slist somewhere (I don't remember where) and _Py_hashtable for the methods cache. Reuse _Py_hashtable for the methods cache is not trivial, the API doesn't fit exactly. I didn't spend much time to try to adapt _Py_hashtable API or the methods cache. _Py_hashtable API is written for performances, not for usability. Useless function calls are denied: they are punished by an assertion error (ex: _Py_hashtable_delete() if the key does not exist). An hash entry contains directly data, so you have to add a pointer with a size to store or retrieve an entry. I like my own API, but others may prefer a different API :-) Anyway, the _Py_hashtable API is fully private and excluded from the stable ABI. What do you think? Should we start by moving them to Modules/ and only move them again if they are used in more than one place? (Another little issue is that "hashtable" looks like Python dict, whereas Python dict is implemeted in Objects/dictobject.c). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18874> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
