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