On Wed, Feb 15, 2017 at 4:05 PM, Ilhan Polat <ilhanpo...@gmail.com> wrote:

> 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. > > While I agree with you that printf format codes are arcane, unfortunately they need to be used here since they are supported by Python: https://docs.python.org/3.1/library/string.html#formatspec > > 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 > >

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