I agree that shipping a sane/sanitising doctest runner would go 95% of the way to alleviating my concerns.
Regarding 2.0, this is the whole point of semantic versioning: downstream packages can pin their dependency as 1.x and know that they
- will continue to work with any updates
- won’t make their users choose between new NumPy 1.x features and running their software.
The Python 3.x transition was a huge fail, but the version numbering was not the problem.
I do have sympathy for Ralf’s argument that "exact repr's are not part of the NumPy (or Python for that matter) backwards compatibility guarantees”. But it is such a foundational project in Scientific Python that I think extreme care is warranted, beyond any official guarantees. (Hence this thread, yes. Thank you!)
Incidentally, I don’t think "array( 1.)” is such a tragic repr fail. I actually would welcome it because I’ve tried to JSON-serialise these buggers quite a few times because I didn’t realise they were 0d arrays instead of floats. So why exactly is it so bad that there is a space there?
Anyway, all this is (mostly) moot if the next NumPy ships with this doctest++ thingy. That would be an enormously valuable contribution to the whole ecosystem.
Thanks,
Juan.
On 1 Jul 2017, 9:56 AM +1000, Robert Kern <robert.kern@gmail.com>, wrote:
On Fri, Jun 30, 2017 at 4:47 PM, Gael Varoquaux <
gael.varoquaux@normalesup.org> wrote:
>
> 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.
It's not that hard: wrap the new `set_printoptions(pad=True)` in a `try:` block to catch the error under old versions.
--
Robert Kern
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion