On http://bugs.python.org/issue9778 you elaborated on what the PEP would entail in its current state:
“No, vice versa. The PEP promises that the ABI won't change until Python 4. For any change that might break the ABI, either a backwards-compatible solution needs to be found, or the change be deferred to Python 4.”
This sounds like it could be detrimental by blocking desired improvements (the aforementioned issue is a potential example of this).
Notice that it's only potential: in the specific case, there would be an ABI-compatible way of introducing wide hashes, using a second type slot.
Do you think it would complicate things a lot to version the ABI itself?
It would miss the point. The ABI deliberately restricts itself to features that really have been stable, and we should be committed to keeping that subset stable. If you think this is too restrictive, please point out specific aspects that you think might need to change in the mid-term future. They should then be excluded from the ABI.
Actually, PYTHON_API_VERSION is already used as some kind of ABI tag (since it's checked at module load time rather than at compile time).
It's too late, though: when the module is being created, the code using the ABI is already running. As I wrote in the issue: the *real* ABI version is "python3.dll". Regards, Martin