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-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
