[Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought

[Travis Oliphant]

>> 
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100525/8d1beda4/attachment.html>