+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.
On Fri, Sep 9, 2022, 07:23 Stefan van der Walt email@example.com 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.
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 : longpi = np.longdouble('3.14159265358979323846') In : longpi Out: 3.1415926535897932385 In : np.longdouble(3.1415926535897932385) # Argument is parsed as 64 bit float Out: 3.141592653589793116 In : np.longdouble('3.1415926535897932385') # Correctly reproduces the longdouble Out: 3.1415926535897932385
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.
NumPy-Discussion mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: firstname.lastname@example.org