[Numpy-discussion] proposed changes to array printing in 1.14

Gael Varoquaux gael.varoquaux at normalesup.org
Fri Jun 30 19:47:21 EDT 2017


One problem is that it becomes hard (impossible?) for downstream packages
such as scikit-learn to doctest under multiple versions of the numpy.
Past experience has shown that it could be useful.

Gaël

On Fri, Jun 30, 2017 at 06:30:53PM -0400, Allan Haldane wrote:
> On 06/30/2017 09:17 AM, Gael Varoquaux wrote:
> > Indeed, for scikit-learn, this would be a major problem.

> > Gaël

> I just ran the scikit-learn tests.

> With the new behavior (removed whitespace), I do get 70 total failures:

>     $ make test-doc
>     Ran 39 tests in 39.503s
>     FAILED (SKIP=3, failures=19)

>     $ make test
>     Ran 8122 tests in 387.650s
>     FAILED (SKIP=58, failures=51)

> After setting `np.set_printoptions(pad_sign=True)` (see other email) I
> get only 1 failure in total, which is due to the presence of a 0d array
> in gaussian_process.rst.

> So it looks like the pad_sign option as currently implemented is good
> enough to avoid almost all doctest errors.

> Allan



> > On Fri, Jun 30, 2017 at 05:55:52PM +1000, Juan Nunez-Iglesias wrote:
> >> To reiterate my point on a previous thread, I don't think this should happen
> >> until NumPy 2.0. This *will* break a massive number of doctests, and what's
> >> worse, it will do so in a way that makes it difficult to support doctesting for
> >> both 1.13 and 1.14. I don't see a big enough benefit to these changes to
> >> justify breaking everyone's tests before an API-breaking version bump.

> >> On 30 Jun 2017, 6:42 AM +1000, Marten van Kerkwijk <m.h.vankerkwijk at gmail.com>,
> >> wrote:

> >>     To add to Allan's message: point (2), the printing of 0-d arrays, is
> >>     the one that is the most important in the sense that it rectifies a
> >>     really strange situation, where the printing cannot be logically
> >>     controlled by the same mechanism that controls >=1-d arrays (see PR).

> >>     While point 3 can also be considered a bug fix, 1 & 4 are at some
> >>     level matters of taste; my own reason for supporting their
> >>     implementation now is that the 0-d arrays already forces me (or,
> >>     specifically, astropy) to rewrite quite a few doctests, and I'd rather
> >>     have everything in one go -- in this respect, it is a pity that this
> >>     is separate from the earlier change in printing for structured arrays
> >>     (which was also much for the better, but broke a lot of doctests).

> >>     -- Marten



> >>     On Thu, Jun 29, 2017 at 3:38 PM, Allan Haldane <allanhaldane at gmail.com>
> >>     wrote:

> >>         Hello all,

> >>         There are various updates to array printing in preparation for numpy
> >>         1.14. See https://github.com/numpy/numpy/pull/9139/

> >>         Some are quite likely to break other projects' doc-tests which expect a
> >>         particular str or repr of arrays, so I'd like to warn the list in case
> >>         anyone has opinions.

> >>         The current proposed changes, from most to least painful by my
> >>         reckoning, are:

> >>         1.
> >>         For float arrays, an extra space previously used for the sign position
> >>         will now be omitted in many cases. Eg, `repr(arange(4.))` will now
> >>         return 'array([0., 1., 2., 3.])' instead of 'array([ 0., 1., 2., 3.])'.

> >>         2.
> >>         The printing of 0d arrays is overhauled. This is a bit finicky to
> >>         describe, please see the release note in the PR. As an example of the
> >>         effect of this, the `repr(np.array(0.))` now prints as 'array(0.)`
> >>         instead of 'array(0.0)'. Also the repr of 0d datetime arrays is now
> >>         like
> >>         "array('2005-04-04', dtype='datetime64[D]')" instead of
> >>         "array(datetime.date(2005, 4, 4), dtype='datetime64[D]')".

> >>         3.
> >>         User-defined dtypes which did not properly implement their `repr` (and
> >>         `str`) should do so now. Otherwise it now falls back to
> >>         `object.__repr__`, which will return something ugly like
> >>         `<mytype object at 0x7f37f1b4e918>`. (Previously you could depend on
> >>         only implementing the `item` method and the repr of that would be
> >>         printed. But no longer, because this risks infinite recursions.).

> >>         4.
> >>         Bool arrays of size 1 with a 'True' value will now omit a space, so
> >>         that
> >>         `repr(array([True]))` is now 'array([True])' instead of
> >>         'array([ True])'.

> >>         Allan
> >>         _______________________________________________
> >>         NumPy-Discussion mailing list
> >>         NumPy-Discussion at python.org
> >>         https://mail.python.org/mailman/listinfo/numpy-discussion

> >>     _______________________________________________
> >>     NumPy-Discussion mailing list
> >>     NumPy-Discussion at python.org
> >>     https://mail.python.org/mailman/listinfo/numpy-discussion


> >> _______________________________________________
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion at python.org
> >> https://mail.python.org/mailman/listinfo/numpy-discussion



> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

-- 
    Gael Varoquaux
    Researcher, INRIA Parietal
    NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France
    Phone:  ++ 33-1-69-08-79-68
    http://gael-varoquaux.info            http://twitter.com/GaelVaroquaux


More information about the NumPy-Discussion mailing list