[Numpy-discussion] Merging the refactor.
Dag Sverre Seljebotn
Fri Nov 12 01:40:18 CST 2010
On 11/11/2010 11:15 PM, Travis Oliphant wrote:
> Thanks for starting the discussion, Charles.
> Merging of the re-factor is a priority for me once I get back from
> last 9 weeks of travel I have been on (I have been travelling for
> business 7 of the last 9 weeks).
> Ilan Schnell has already been looking at how to accomplish the merge
> (and I have been reading up on Git so that I understand the commit
> model better and can possibly help without being a complete neophyte
> with git). Pauli's script will be very helpful.
> I'm very enthused about the bug-fixes, memory-leak closures, and new
> tests that have been added on the re-factor branch. I'm also
> interested in getting more community feedback on the ndarray library
> C-API, and the other changes that have been made. This feedback
> will be essential before the changes can become NumPy 2.0. I would
> also like to see a few more NEPs become part of NumPy 2.0 over the
> next several months. I have a long wish list of additional NEPS that
> I've only sketched in quick drafts at this point as well --- datetime
> finishes, geometry-information, i.e. dimension and index labels,
> reduce-by implementation, indirect arrays, and generator array objects.
> My initial guess as to how quickly we would have a NumPy 2.0 was
> ambitious partly because I have had almost zero time personally to
> work on it, and partly because we have been resource constrained which
> has pushed us to draw out the project a bit. But, I've come up
> with a long list of new features for NumPy 2.0 that I would like to
> hash out on the mailing lists over the next months as well. My hope
> is for NumPy 2.0 to come out by the end of Q1 sometime next year. My
> hopes may have to be tempered by limited time resources, of course.
Conventionally, 2.0 would be the preferred point to break backwards
compatability (and changes that could break stability), while simply
adding new backwards compatible features can just as well be done in 2.1.
IMO the crucial question is: Would it be possible to split this long
list you have in mind in this fashion? And how much remains that will
break backwards compatibility or cause instability?
> At the same time, the work on the .NET framework has pushed us to move
> more of SciPy to a Cython-generated set. There are additional things
> I would like to see SciPy improve on as well, but I am not sure who is
> going to work on them. If I had my dream, there would be more
> modularity to the packages, and an improved packaging system --- and
> of course, porting to Python 3k. I would like to see core SciPy be a
> smaller set containing a few core packages. (linear algebra,
> statistics, optimization, interpolation, signal processing, and image
> processing). Then, I would like to see scipy.<module> packages which
> are released and packaged separately with the whole system available
> on github.
> The past couple of years have been very busy for me (and continue to
> be busy), but I am hoping that next year will allow me more time to
> spend on promoting sprints, and participating more in the community.
> I will not have the time I used to have when I was a full-time
> academic, but I plan to be more involved in helping promote SciPy
> development. With SciPy moved over to github, I think that will even
> be possible without my stepping on everybody else's hard work.
> I have forwarded th
> On Nov 11, 2010, at 9:30 PM, Charles R Harris wrote:
>> On Thu, Nov 11, 2010 at 2:08 PM, Pauli Virtanen <email@example.com
>> <mailto:firstname.lastname@example.org>> wrote:
>> On Thu, 11 Nov 2010 12:38:53 -0700, Charles R Harris wrote:
>> > I'd like to open a discussion about the steps to be followed in
>> > the numpy refactor. I have two concerns about this. First, the
>> > repository branched off some time ago and I'm concerned about code
>> > divergence, not just in the refactoring, but in fixes going
>> into the
>> > master branch on github. Second, it is likely that a flag day
>> will look
>> > like the easiest solution and I think we should avoid that.
>> What is a "flag day"?
>> It all goes in as one big commit.
>> > At the moment it seems to me that the changes can be broken up into
>> > three categories:
>> > 1) Movement of files and resulting changes to the build process.
>> > 2) Refactoring of the files for CPython.
>> > 3) Addition of an IronPython interface.
>> > I'd like to see 1) go into the master branch as soon as possible,
>> > followed by 2) so that the changes can be tested and fixes will
>> go into
>> > a common repository. The main github repository can then be
>> branched for
>> > adding the IronPython stuff. In short, I think it would be
>> usefull to
>> > abandon the teoliphant fork at some point and let the work
>> continue in a
>> > fork of the numpy repository.
>> The first step I would like to see is to re-graft the teoliphant
>> onto the current Git history -- currently, it's still based on
>> Re-grafting would make incremental merging and tracking easier.
>> this is easy to do thanks to Git's data model (I have a script
>> for it),
>> and I believe it could be useful to do it ASAP.
>> I agree that would be an excellent start. Speaking of repo surgery,
>> you might find esr's latest project <http://esr.ibiblio.org/?p=2727>
>> of interest.
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org>
> Travis Oliphant
> Enthought, Inc.
> email@example.com <mailto:firstname.lastname@example.org>
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion