On Thu, Oct 8, 2009 at 11:39 AM, Travis Oliphant
I apologize for the mis communication that has occurred here.
No problem
I did not understand that there was a desire to keep ABI compatibility with NumPy 1.3 when NumPy 1.4 was released. The datetime merge was made under that presumption. I had assumed that people would be fine with recompilation of extension modules that depend on the NumPy C-API. There are several things that needed to be done to merge in new fundamental data-types. Why don't we call the next release NumPy 2.0 if that helps things? Personally, I'd prefer that over hacks to keep ABI compatibility.
Keeping ABI compatibility by itself is not an hack - the current workaround is an hack, but that's only because the current way of doing things in code generator is a bit ugly, and I did not want to spend too much time on it. It is purely an implementation issue, the fundamental idea is straightforward. If you want a cleaner solution, I can work on it. I think the hour or so that it would take is worth it compared to breaking many people's code.
It feels like we are working very hard to track ABI issues that can also be handled with dependency checking and good package management.
I think ABI issues are mostly orthogonal to versioning - generally, versions are related to API changes (API changes is what should drive ABI changes, at least for projects like numpy). I would prefer passing to "numpy 2.0" when we really need to break ABI and API - at that point, I think we should also think hard about changing our structures and all to make them more robust to those changes (using pimp-like strategies in particular). David