> > I encourage you to submit it as a pull request to the NumPy repository as > a "NumPy Enhancement Proposal", either now or after we've discussed it: > https://docs.scipy.org/doc/numpy-dev/neps/index.html
OK, I will let it go through one iteration of comments and then I'll submit one. Thanks! 1. For object arrays, I would default to calling format on each element > (your "map principle") rather than raising an error. I'm glad you brought this up as a possibility. It might be possible, but there are some issues that would need to be resolved. First of all, {} and {:} always works and gives the same result it currently does. So, this only affects the situation where the format spec is non-empty. I think there are two main issues: Heterogeneity: Let's say we have x = np.array([12.3, True, 'string', Foo(10)], dtype=np.object). Then, presumably {:.1f} should cause a ValueError since the string does not support format type 'f'. This could create a lot of ValueError land mines for the user. For x[:2] however it should work and produce something like [12.3 1.0]. Note, the "map principle" still can't be strictly true. Let's say we have an array with type object and mostly string-like elements. Then {:5s} will still not produce exactly {:5s} element-wise, because the string representations need to be repr-based inside the array (otherwise it could break for newlines and things like that and produce spaces that make the boundary between elements ambiguous). This brings me to the next issue. Str vs. repr: If we have a homogeneous object-array with types Foo and Foo implements __format__, it would be great if this worked. However, one issue is that Foo.__format__ might return things like newline (or spaces), which would break (or confuse) the printed output (unless it is made incredibly smart to support "vertical alignment"). This issue is essentially the same as for strings in general, which is why they use repr instead. I can think of two solutions: 1) Try to sanitize (or repr-ify) the string returned by __format__ somehow; 2) Put the responsibility on the user and simply let the rendering break if Foo.__format__ does not play well. 2. It's absolutely OK to leave functionality unimplemented and not > immediately nail down every edge case. As a default, I would suggest > raising errors whenever non-empty type specifications are provided rather > than raising errors in every case. > I agree. Gustav On Tue, Feb 14, 2017 at 3:59 PM, Stephan Hoyer <sho...@gmail.com> wrote: > On Tue, Feb 14, 2017 at 3:34 PM, Gustav Larsson <lars...@cs.uchicago.edu> > wrote: > >> Hi everyone! >> >> I want to discuss adding support for __format__ in ndarray and I am >> willing to >> contribute code-wise once consensus has been reached. It was briefly >> discussed on GitHub two years ago (https://github.com/numpy/nump >> y/issues/5543) >> and I will re-iterate some of the points made there and build off of >> that. I >> have been thinking about this a lot in the last few weeks and my thoughts >> turned >> into a fairly fleshed out proposal. The discussion should probably start >> more >> high-level, so I apologize if the level of detail is inappropriate at this >> point in time. >> >> I decided on a gist, since the email got too long and clear formatting >> helps: >> >> https://gist.github.com/gustavla/2783543be1204d2b5d368f6a1fb4d069 > > > This is a lovely and clearly written document. Thanks for taking the time > to think through this! > > I encourage you to submit it as a pull request to the NumPy repository as > a "NumPy Enhancement Proposal", either now or after we've discussed it: > https://docs.scipy.org/doc/numpy-dev/neps/index.html > > >> OK, those are my thoughts for now. What do you think? >> > > Two thoughts for now: > 1. For object arrays, I would default to calling format on each element > (your "map principle") rather than raising an error. > 2. It's absolutely OK to leave functionality unimplemented and not > immediately nail down every edge case. As a default, I would suggest > raising errors whenever non-empty type specifications are provided rather > than raising errors in every case. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion