Codecov Report

Attention: Patch coverage is 82.41758% with 16 lines in your changes missing coverage. Please review.

Project coverage is 86.54%. Comparing base (b495c70) to head (850fb77).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #226      +/-   ##
==========================================
- Coverage   86.77%   86.54%   -0.24%     
==========================================
  Files          49       49              
  Lines        3797     3858      +61     
==========================================
+ Hits         3295     3339      +44     
- Misses        502      519      +17     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

basic idea looks good. lemme know when ready for a full review. How do you plan to manage when it switches into scientific notation?

Currently, it depends on str(float), as for big values, on my machine it uses scientific notation. I need to check how universal it is.

hey @Czaki, gentle ping on this PR. still interested in adding this?

Yes. But I'm not sure if I will find time before January (Christmas etc).

K, no hurry. Enjoy

Hi @Czaki,
Thank you for the implementation.
By the way, I've looked for an explicit specification that stated str(float) used scientific notation when necessary (i.e General Format, 'g')
I could not find that statement but at least I found that cpython implementation was working like that.
str(float) uses General Format by default.

Here are what I found.
I hope it helps you save time.

1. From Python Doc. for str()

   str(object) returns type(object).__str__(object), which is the “informal” or nicely printable string representation of object. For string objects, this is the string itself. If object does not have a __str__() method, then str() falls back to returning repr(object).

   so str(float) will call float.__str__() or float.__repr__()

2. Python float does not have __str__() but have __repr()__. See PyTypeObject PyFloat_Type.

3. float_repr() which float.__repr__ is mapped to calls PyOS_double_to_string() with format_code of 'r'.

   static PyObject *
   float_repr(PyFloatObject *v)
   {
       PyObject *result;
       char *buf;
   
       buf = PyOS_double_to_string(PyFloat_AS_DOUBLE(v),
                                   'r', 0,
                                   Py_DTSF_ADD_DOT_0,
                                   NULL);
       if (!buf)
           return PyErr_NoMemory();
       result = _PyUnicode_FromASCII(buf, strlen(buf));
       PyMem_Free(buf);
       return result;
   }

4. Finally, PyOS_double_to_string() uses 'g'(General Format) option for 'r' format code.

   case 'r':          /* repr format */
   /* Supplied precision is unused, must be 0. */
   if (precision != 0) {
       PyErr_BadInternalCall();
       return NULL;
   }
   /* The repr() precision (17 significant decimal digits) is the
      minimal number that is guaranteed to have enough precision
      so that if the number is read back in the exact same binary
      value is recreated.  This is true for IEEE floating point
      by design, and also happens to work for all other modern
      hardware. */
   precision = 17;
   format_code = 'g';
   break;

so, I think your choice of using str(float) is good.

Thank you.

-- Jake

@tlambert03 may you take a look on the implementation of setValue to tell what did you think about the logic to converting to string?

Maybe the minimum and maximum limits should be more flexible:

Did I need to add more tests before a review?

nope, sorry, I missed the request mark.