[Numpy-discussion] numpy 2.0, what else to do?

Joe Harrington jh@physics.ucf....
Sat Feb 13 12:23:04 CST 2010


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--


More information about the NumPy-Discussion mailing list