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