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

Pauli Virtanen pav at iki.fi
Sat Feb 13 15:28:03 EST 2010


We will most likely have experimental py3 support in 2.0.

If you, or someone else wishes to help bringing 2.0 to fully work with Py3, now is a very good time to step up.

How to give a hand:

1. Get my latest py3 branch from http://github.com/pv/numpy-work/tree/py3k

Read doc/py3k.txt

2. Get py3 branch of nose (see doc/py3k.txt in the branch). 

3. Build numpy, and run unit tests (build with "NPY_SEPARATE_BUILD=1 python3 setup.py build", numscons is not supported at the moment).

4. Fix bugs revealed by the unit tests. Currently, C code is mostly ported, so you can probably also help only by writing Python. There are about 100 test failures (of 2400) left.

Many test failures occur also because the tests are wrong. For instance: the numpy I/O requires bytes, but some tests supply it unicode strings -> need changes in tests.

One useful thing to do is to help with the str/bytes transition on the python side. Since the same code must work with pythons from 2.4 to 3.0 (for 3 it's automatically run through 2to3 on build), there are some helpers in numpy.compat.py3k for helping with this. See several previous commits on the branch on that.

Another useful thing could be to port an existing numpy-using code to py3 and test if it works with the current py3k branch, what fails, and if the failures are already revealed by unit tests. Even if it does not work at the moment, having it at hand will help testing the rc when it comes. This, because I wouldn't completely rely on our unit test coverage.

Finally, try to write some PEP 3118 using code, and check how it works. (You can use python >= 2.6 for this if you get numpy from the py3k branch.)

-- 
Pauli Virtanen
----- Alkuperäinen viesti -----
> IMHO 2.0 should support python3.
> That would be a major step and a good reason to call it 2.0.
>
> Xavier
>
> > 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 <jh at 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 at scipy.org
> > > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> > >       
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> >   
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion




More information about the NumPy-Discussion mailing list