This is exactly what I was worried about with calling the next release 2.0.
This is not the time to change all the things we wish were done differently. The release is scheduled for 3 weeks. Travis -- (mobile phone of) Travis Oliphant Enthought, Inc. 1-512-536-1057 http://www.enthought.com On Feb 13, 2010, at 12:23 PM, Joe Harrington <j...@physics.ucf.edu> wrote: > Chuck Harris writes (on numpy-discussion): > >> Since there has been talk of deprecating the numarray and numeric >> compatibility parts of numpy for the upcoming 2.0 release I thought >> maybe we >> could consider a few other changes. First, numpy imports a ton of >> stuff by >> default and this is maintained for backward compatibility. Would >> this be a >> reasonable time to change that and require explicit imports for >> things like >> fft? Second, Poly1D has problems that aren't likely to get fixed, I >> would >> like to both deprecate the old polynomial support and make it not be >> imported by default. >> >> Thoughts? > > I'd like to suggest that 2.0 include a fully-reviewed set of > docstrings (except for the "unimportant" ones). > > Really, 1.0 should not have been released without documentation, but > it was released prematurely anyway, and we've spent much of the 1.x > release series fixing inconsistencies and other problems, as well as > writing the draft docs now included in the releases. I look at 2.0 > as our "real" 1.0, as do many others. > > I am posting a call for a (possibly paid) Django programmer who can > add a second review capability to the doc wiki. That call is on > scipy-dev, where discussion of the wiki and general documentation > topics takes place. If you are interested, please respond there, not > here. Discussion of whether to include reviewed docs in numpy 2.0 > belongs here on numpy-discussion, of course. > > I think the main issue with regard to docs will be time frame. What > is the time frame for a 2.0 release? > > Aside from docs and the things Chuck mentioned, I think a general > design review would be a good idea, to root out things like any more > lurking inconsistencies or disorganizations, such as the "median" > problem. I guess that's what Chuck started, but should we formalize > it by parceling out chunks of the package to 2-3 reviewers each for > comment? The idea would be to root out problems, incompleteness, and > disorganization, *not* to engage in a big rewrite that would massively > break the API for everyone. > > Ideally, after 2.0 the changes would be improvements rather than > API-breaking fixes. > > Thanks, > > --jh-- > _______________________________________________ > 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
