+1 from me. They are a frequent source of confusion when starting, and there appear to be far fewer now then in earlier releases.   It also might make it easier to spot any inadvertent scalars coming out if these could be Python floats.  

Kevin

On Fri, Sep 9, 2022, 07:23 Stefan van der Walt <stefanv@berkeley.edu> wrote:

I am in favor of such a change. It will make what is returned more transparent to users (and reduce confusion for newcomers).

With NEP50, we're already adopting a philosophy of explicit scalar usage anyway: no longer pretending or trying to make transparent that Python floats and NumPy floats are the same.

No one *actually* round-trips objects via repr, but if a user could look at a result and know how to construct the object, that is an improvement.

Stéfan

On Thu, Sep 8, 2022, at 22:26, Matti Picus wrote:
> On 9/9/22 04:15, Warren Weckesser wrote:
>> ...
>> To quote from https://docs.python.org/3/library/functions.html#repr:
>>
>>> For many types, this function makes an attempt to return a string
>>> that would yield an object with the same value when passed to eval();
>> Sebastian, is this an explicit goal of the change?  (Personally, I've
>> gotten used to not taking this too seriously, but my world view is
>> biased by the long-term use of NumPy, which has never followed this
>> guideline.)
>>
>> If that is a goal, than the floating point types with precision
>> greater than double precision will need to display the argument of the
>> type as a string.  For example, the following is run on a platform
>> where numpy.longdouble is extended precision (80 bits):
>>
>> ```
>> In [161]: longpi = np.longdouble('3.14159265358979323846')
>>
>> In [162]: longpi
>> Out[162]: 3.1415926535897932385
>>
>> In [163]: np.longdouble(3.1415926535897932385)  # Argument is parsed
>> as 64 bit float
>> Out[163]: 3.141592653589793116
>>
>> In [164]: np.longdouble('3.1415926535897932385')  # Correctly
>> reproduces the longdouble
>> Out[164]: 3.1415926535897932385
>> ```
>>
>> Warren
>
>
> As others have mentioned, the change will greatly enhance UX at the cost
> of documentation cleanups. While the representation may not be perfectly
> roundtrip-able, I think it still is an improvement and worthwhile.
> Elsewhere I have suggested we need more documentation around
> array/scalar printing, perhaps that would be a place to mention the
> limitations of string representations.
>
> Matti
_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-leave@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: kevin.k.sheppard@gmail.com

_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-leave@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: evgeny.burovskiy@gmail.com