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 vstinner
Recipients amaury.forgeotdarc, belopolsky, neologix, python-dev, rhettinger, tim.peters, vstinner
Date 2013-11-21.11:50:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1385034606.68.0.574886532786.issue18874@psf.upfronthosting.co.za>
In-reply-to
Content
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).
History
Date User Action Args
2013-11-21 11:50:06vstinnersetrecipients: + vstinner, tim.peters, rhettinger, amaury.forgeotdarc, belopolsky, neologix, python-dev
2013-11-21 11:50:06vstinnersetmessageid: <1385034606.68.0.574886532786.issue18874@psf.upfronthosting.co.za>
2013-11-21 11:50:06vstinnerlinkissue18874 messages
2013-11-21 11:50:06vstinnercreate