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.vankerkw...@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 <allanhald...@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@python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion@python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > >> _______________________________________________ > >> NumPy-Discussion mailing list > >> NumPy-Discussion@python.org > >> https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion