[Numpy-discussion] numpy 2.0, what else to do?
Sat Feb 13 13:53:46 CST 2010
IMHO 2.0 should support python3.
That would be a major step and a good reason to call it 2.0.
> This is exactly what I was worried about with calling the next release
> This is not the time to change all the things we wish were done
> The release is scheduled for 3 weeks.
> (mobile phone of)
> Travis Oliphant
> Enthought, Inc.
> On Feb 13, 2010, at 12:23 PM, Joe Harrington <email@example.com> 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
>>> like to both deprecate the old polynomial support and make it not be
>>> imported by default.
>> 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.
>> NumPy-Discussion mailing list
> NumPy-Discussion mailing list
More information about the NumPy-Discussion