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