Changes between Initial Version and Version 1 of Ticket #26311


Ignore:
Timestamp:
09/19/18 12:54:41 (19 months ago)
Author:
embray
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #26311 – Description

    initial v1  
    2727
    2828as expected.
     29
     30The problem appears to stem from the (relatively) new !PyTime API, and in particular this function:
     31
     32{{{
     33static int
     34_PyTime_FromObject(_PyTime_t *t, PyObject *obj, _PyTime_round_t round,
     35                   long unit_to_ns)
     36{
     37    if (PyFloat_Check(obj)) {
     38        double d;
     39        d = PyFloat_AsDouble(obj);
     40        if (Py_IS_NAN(d)) {
     41            PyErr_SetString(PyExc_ValueError, "Invalid value NaN (not a number)");
     42            return -1;
     43        }
     44        return _PyTime_FromFloatObject(t, d, round, unit_to_ns);
     45    }
     46    else {
     47        long long sec;
     48        Py_BUILD_ASSERT(sizeof(long long) <= sizeof(_PyTime_t));
     49
     50        sec = PyLong_AsLongLong(obj);
     51        if (sec == -1 && PyErr_Occurred()) {
     52            if (PyErr_ExceptionMatches(PyExc_OverflowError))
     53                _PyTime_overflow();
     54            return -1;
     55        }
     56
     57        if (_PyTime_check_mul_overflow(sec, unit_to_ns)) {
     58            _PyTime_overflow();
     59            return -1;
     60        }
     61        *t = sec * unit_to_ns;
     62        return 0;
     63    }
     64}
     65}}}
     66
     67So it does not properly handle custom types that implement `__float__`.  I will raise a complaint about that.  In the meantime I don't see that there's much to be done except to always wrap Sage types in `float()` before passing them to time functions (or, more extreme, provide our own wrappers for common time functions...)