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.

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.

On Nov 11, 2010, at 9:30 PM, Charles R Harris wrote:

On Thu, Nov 11, 2010 at 2:08 PM, Pauli Virtanen <pav@iki.fi> 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 merging
> the numpy refactor. I have two concerns about this. First, the refactor
> 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 branch
onto the current Git history -- currently, it's still based on Git-SVN.
Re-grafting would make incremental merging and tracking easier. Luckily,
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 of interest.

<snip>

Chuck

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

---

Travis Oliphant

Enthought, Inc.

oliphant@enthought.com

1-512-536-1057

http://www.enthought.com