On May 25, 2010, at 4:49 PM, David Goldsmith wrote: > Travis: do you already have a place on the NumPy Development Wiki where > you're (b)logging your design decisions? Seems like a good way for concerned > parties to monitor your choices in more or less real time and thus provide > comment in a timely fashion.
This is a great idea of course and we will definitely post progess there. So far, the code has been reviewed and several functions identified for re-factoring. This is taking place in a github branch of numpy called numpy refactor. -Travis > > DG > > On Tue, May 25, 2010 at 2:19 PM, Charles R Harris <charlesr.har...@gmail.com> > wrote: > > > On Tue, May 25, 2010 at 2:54 PM, Travis Oliphant <oliph...@enthought.com> > wrote: > > On May 25, 2010, at 2:50 PM, Charles R Harris wrote: > >> >> >> On Tue, May 25, 2010 at 1:37 PM, Travis Oliphant <oliph...@enthought.com> >> wrote: >> >> Hi everyone, >> >> There has been some talk about re-factoring NumPy to separate out the >> Python C-API layer and make NumPy closer to a C-library. I know >> there are a few different ideas about what this means, and also that >> people are very busy. I also know there is a NumPy 2.0 release that >> is in the works. >> >> I'm excited to let everyone know that we (at Enthought) have been able >> to find resources (about 3 man months) to work on this re-factoring >> project and Scott and Jason (both very experienced C and Python >> programmers) are actively pursuing it. My hope is that NumPy 2.0 >> will contain this re-factoring (which should be finished just after >> SciPy 2010 --- where I'm going to organize a Sprint on NumPy which >> will include at least date-time improvements and re-factoring work). >> >> While we have specific goals for the re-factoring, we want this >> activity to be fully integrated with the NumPy community and Scott and >> Jason want to interact with the community as much as feasible as they >> suggest re-factoring changes (though they both have more experience >> with phone-conversations to resolve concerns than email chains and so >> some patience from everybody will be appreciated). >> >> Because Jason and Scott are new to this mailing list (but not new to >> NumPy), I wanted to introduce them so they would feel more >> comfortable posting questions and people would have some context as to >> what they were trying to do. >> >> Scott and Jason are both very proficient and skilled programmers and I >> have full confidence in their abilities. That said, we very much >> want the input of as many people as possible as we pursue the goal of >> grouping together more tightly the Python C-API interface layer to >> NumPy. >> >> I will be involved in some of the discussions, but am currently on a >> different project which has tight schedules and so I will only be able >> to provide limited "mailing-list" visibility. >> >> >> 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. > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > -- > Mathematician: noun, someone who disavows certainty when their uncertainty > set is non-empty, even if that set has measure zero. > > Hope: noun, that delusive spirit which escaped Pandora's jar and, with her > lies, prevents mankind from committing a general suicide. (As interpreted by > Robert Graves) > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. oliph...@enthought.com 1-512-536-1057 http://www.enthought.com
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
