I'm a potential user of the C-API and therefore I'm very interested in the outcome. In the previous discussion (http://comments.gmane.org/gmane.comp.python.numeric.general/37409) many different views on what the new C-API "should" be were expressed.
Naturally, I wonder if the new C-API will be useful for my purposes. So, I'm not so excited about a "refactoring log" where only the progress is reported. I fear that some (potentially minor) design decisions would render the new C-API useless for me. So my question is: Does this "refactoring log" also include something like a Numpy Enhancement Proposal? Something that can be discussed beforehand? I.e., will there be a detailed description (i.e. code examples) what the goal of the refactoring is? If there is any interest, I could provide some simple test examples in C that would explain what I'd like to be able to do with the new C-API. Sebastian On Wed, May 26, 2010 at 8:21 AM, David Goldsmith <d.l.goldsm...@gmail.com> wrote: > On Tue, May 25, 2010 at 9:22 PM, Travis Oliphant <oliph...@enthought.com> > wrote: >> >> 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. >> > > Thanks; specific URL please, when available; plus, prominently feature (a > link to) the location on the Development Wiki home page, at the very least > (i.e., if not also on the NumPy home page). > >> >> So far, the code has been reviewed, > > I.e., the existing code, yes? > >> >> and several functions identified for re-factoring. > > Please enumerate on the "Wiki Refactoring Log" (name tentative - I don't > care what we call it, just so long as it exists, its purpose is clear, and > we all know where it is). > >> This is taking place in a github branch of numpy called numpy refactor. > > "This" = the actual creation/modification of code, yes? > > DG >> >> -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 >> > > > > -- > 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 > > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
