> Agreed in general, but in this case, it's really not that easy. A C > function call involves a certain overhead all by itself, so calling into > the C-API multiple times may be substantially more costly than, say, > calling through a function pointer once and then running over a returned C > array comparing numbers. And definitely way more costly than running over > an array that the type struct points to directly. We are not talking about > hundreds of entries here, just a few. A linear scan in 64 bit steps over > something like a hundred bytes in the L1 cache should hardly be measurable. I give up, then. I fail to understand the problem. Apparently, you want to do something with the value you get from this lookup operation, but that something won't involve function calls (or else the function call overhead for the lookup wouldn't be relevant). 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). As this is apparently only relevant to speed fanatics, too, I suggest that you check how fast PyPI works for you. Supposedly, they have very efficient lookup procedures, supported by the JIT. If this doesn't work for some reason, I suggest that you'll have to trade speed for convenience: a compile-time fixed layout will beat any dynamic lookup any time. Just define a common base class, and have all interesting types inherit from it. 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