> In our specific case the value would be an offset added to the > PyObject*, and there we would find a pointer to a C function (together > with a 64-bit signature), and calling that C function (after checking > the 64 bit signature) is our final objective. And what the C function does really is faster than the lookup through a dictionary? I find that hard to believe. >> I still think this is out of scope for python-dev. If this is something >> you want to be able to do for Python 2.4 as well, then you don't need >> any change to Python - you can do whatever you come up with for all >> Python versions, no need to (or point in) changing Python 3.4 (say). > > We can go ahead and hijack tp_flags bit 22 to make things work in > existing versions. But what if Python 3.8 then starts using that bit for > something else? Use flag bit 23 in Python 3.8. You know at compile time what Python version you have. > >> As this is apparently only relevant to speed fanatics, too, I suggest >> that you check how fast PyPI works for you. > > Did you mean PyPy? Oops, yes - Freudian slip :-) Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4