On the last item, do we really have to follow that strange, `d`,`g` and so on conventions on formatting? With all respect to the humongous historical baggage, I think that notation is pretty archaic and terminal like. If being pythonic is of a concern here, maybe it is better to use a more verbose syntax. Just throwing out an idea after 15 seconds of thought (so by no means an alternative suggestion)

eng:6i5d -> engineering notation (always powers of ten of multiples of 3) 6 integral digits and 5 decimal digits. float (whatever the default is) float:4i2d (you get the idea) etc. FULL DISCLOSURE: I am a very displeased customer of `fprintf ` of matlab (and others) and this archaic formatting. I never got a hang of it so it might be the case that I don't quite get the rationale behind it and I almost always get it wrong. Maybe at least the rationale can be clarified. Lastly, repeating what others mentioned: thank you for this well prepared initiative On Wed, Feb 15, 2017 at 10:48 PM, Gustav Larsson <lars...@cs.uchicago.edu> wrote: > This is great! > > > Thanks! Glad to be met by enthusiasm about this. > > 1. You basically have a NEP already! Making a PR from it allows to >> give line-by-line comments, so would help! > > > I will do this soon. > > 2. Don't worry about supporting python2 specifics; just try to ensure >> it doesn't break; I would not say more about it! > > > Sounds good to me. > > 3. On `set_printoptions` -- ideally, it will become possible to use >> this as a context (i.e., `with set_printoption(...)`). It might make >> sense to have an `override_format` keyword argument to it. > > > Having a `with np.printoptions(...)` context manager is a great idea. It > does sound orthogonal to __format__ though, so it could be addressed > separately. > > 4. Otherwise, my main suggestion is to start small with the more >> obvious ones, and not worry too much about format validation, but >> rather about getting the simple ones to work well (e.g., for an object >> array, just apply the format given; if it doesn't work, it will error >> out on its own, which is OK). > > > Sounds good to me. I was thinking of approaching the implementation by > writing unit tests first and group them into different priority tiers. That > way, the unit tests can go through another review before implementation > gets going. I agree that __format__ doesn't have to check format validation > if a ValueError is going to be raised anyway by sub-calls. > > 5. One bit of detail: the "g" one does confuse me. > > > I will re-write this a bit to make it clearer. Basically, the 'g' with the > mix of 'e'/'f' depending on max/min>1000 is all from the current numpy > behavior, so it is not something I had much creative input on at all. > Although, as it is written right now it may seem so. That is, the goal is > to have {:} == {:g} for float arrays, analogous to how {:} == {:g} for > built-in floats. Then, if the user departs a bit, like {:.2g}, it will > simply be identical to calling np.set_printoptions(precision=2) first. > > Gustav > > On Wed, Feb 15, 2017 at 8:03 AM, Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> Hi Gustav, >> >> This is great! A few quick comments (mostly echo-ing Stephan's). >> >> 1. You basically have a NEP already! Making a PR from it allows to >> give line-by-line comments, so would help! >> >> 2. Don't worry about supporting python2 specifics; just try to ensure >> it doesn't break; I would not say more about it! >> >> 3. On `set_printoptions` -- ideally, it will become possible to use >> this as a context (i.e., `with set_printoption(...)`). It might make >> sense to have an `override_format` keyword argument to it. >> >> 4. Otherwise, my main suggestion is to start small with the more >> obvious ones, and not worry too much about format validation, but >> rather about getting the simple ones to work well (e.g., for an object >> array, just apply the format given; if it doesn't work, it will error >> out on its own, which is OK). >> >> 5. One bit of detail: the "g" one does confuse me. >> >> All the best, >> >> Marten >> _______________________________________________ >> 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 > >

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion