[Numpy-discussion] Proposal to support __format__

[Nathan Goldbaum]

On Wed, Feb 15, 2017 at 4:05 PM, Ilhan Polat <ilhanpolat at 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 <larsson at 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.vankerkwijk at 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 at scipy.org
>>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20170215/d41dfad2/attachment.html>