>> >> I think 2.0 would be a bit early for this. Is there any reason it couldn't >> be done in 2.1? What is the planned policy with regards to the visible >> interface for extensions? It would also be nice to have a rough idea of how >> the resulting code would be layered, i.e., what is the design for this >> re-factoring. Simply having a design would be a major step forward. > > The problem with doing it in 2.1 is that this re-factoring will require > extensions to be re-built. The visible interface to extensions will not > change, but there will likely be ABI incompatibility. It seems prudent to > do this in NumPy 2.0. Perhaps we can also put in place the ABI-protecting > indirection approaches that David C. was suggesting earlier. > > Some aspects of the design are still being fleshed out, but the basic idea is > to separate out a core library that is as independent of the Python C-API as > possible. There will likely be at least some dependency on the Python > C-API (reference counting and error handling and possibly others) which any > interface would have to provide in a very simple Python.h -- equivalent, for > example. > > Our purpose is to allow NumPy to be integrated with other languages or other > frameworks systems without explicitly relying on CPython. There are a lot > of questions as to how this will work, and so much of that is being worked > out. Part of the reason for this mail is to help ensure that as much of > this discussion as possible takes place in public. > > > Sounds good, but what if it doesn't get finished in a few months? I think we > should get 2.0.0 out pronto, ideally it would already have been released. I > think a major refactoring like this proposal should get the 3.0.0 label. > Admittedly that makes keeping a refactored branch current with fixes going > into the trunk a hassle, but perhaps that can be worked around somewhat by > clearly labeling what files will be touched in the refactoring and possibly > rearranging the content of the existing files. This requires a game plan and > a clear idea of the goal. Put simply, I think the proposed schedule is too > ambitious and needs to be fleshed out. This refactoring isn't going to be as > straight forward as the python3k port because a lot of design decisions need > to be made along the way.
You are correct that there is not much time. However, our timeline is middle of July and we do have dedicated resources. I was also hoping to have discussions at SciPy to accelerate the process. -Travis
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
