PyNumber_Float counterpart that doesn't accept strings

[mdickinson]

BPO	32794
Nosy	@mdickinson, @serhiy-storchaka

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2018-02-08.19:25:33.597>
created_at = <Date 2018-02-08.09:07:52.660>
labels = ['interpreter-core', 'type-feature', '3.8']
title = "PyNumber_Float counterpart that doesn't accept strings"
updated_at = <Date 2018-02-08.19:25:33.595>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2018-02-08.19:25:33.595>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2018-02-08.19:25:33.597>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2018-02-08.09:07:52.660>
creator = 'mark.dickinson'
dependencies = []
files = []
hgrepos = []
issue_num = 32794
keywords = []
message_count = 4.0
messages = ['311819', '311823', '311824', '311845']
nosy_count = 2.0
nosy_names = ['mark.dickinson', 'serhiy.storchaka']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue32794'
versions = ['Python 3.8']

[mdickinson]

Our abstract objects layer in the C-API includes PyNumber_Float [1], which is equivalent to a Python-level float call, including the behaviour of accepting strings. I'm not convinced that it's a particularly useful function: I suspect that it's more common to need to either convert a string to a float, or to convert a float-y object (i.e., something whose type implements float) to a float, but not both at once. The second need is precisely the one that most of the math module has: accept anything that implements float, but don't accept strings.

Yesterday I found myself writing the following code for a 3rd-party extension module:

static PyObject *
_validate_float(PyObject *value) {
    double value_as_double;

    /* Fast path: avoid creating a new object if it's not necessary. */
    if (PyFloat_CheckExact(value)) {
        Py_INCREF(value);
        return value;
    }

    value_as_double = PyFloat_AsDouble(value);
    if (value_as_double == -1.0 && PyErr_Occurred()) {
        return NULL;
    }
    return PyFloat_FromDouble(value_as_double);
}

Would it be worth adding a new C-API level function that does essentially the above? The semantics of such a function seem clear cut. The major problem would be figuring out what to call it, since to me PyNumber_Float is the one obvious name for such behaviour, but it's already taken. :-)

Please note that I'm not suggesting removing / deprecating / changing the existing PyNumber_Float. That would amount to gratuitous breakage.

[1] https://docs.python.org/3.6/c-api/number.html#c.PyNumber_Float

[serhiy-storchaka]

Maybe use PyNumber_Check() to distinguish these two cases?

    if (PyNumber_Check(obj))
        return PyNumber_Float(obj);
    PyErr_SetString(PyExc_TypeError, "not a number");
    return NULL;

[serhiy-storchaka]

For converting a string to a float there is PyFloat_FromString(). So that this part of functionality of PyNumber_Float() is redundant. In long perspective it would be worth to deprecate it.

[mdickinson]

Maybe use PyNumber_Check() [...]

Ah, that works. It reads better than the PyFloat_AsDouble solution, too, since it's far from obvious that PyFloat_AsDouble goes to the trouble to coerce a float-y thing to a float.

I did some searching around to see if I could find evidence that anyone besides me thinks this is a good idea, but I didn't come up with much. In the NumPy source, for example, it's more common to want a C double than another Python object, and I guess that's going to be true for other 3rd party libraries, too.

And I'm also realising that part of what I need here is a *Python*-level solution to the problem, something like this:

def _validate_float(value):
    """
    Coerce an arbitrary Python object to a float, or raise TypeError.
    """
    if type(value) is float:  # fast path for common case
        return value
    try:
        nb_float = type(value).__float__
    except AttributeError:
        raise TypeError(
            "Object of type {!r} not coerceable to float".format(type(value)))
    return nb_float(value)

(and the _validate_float I posted earlier was really just there because the C extension module needed to be able to do the same thing as the equivalent Python code above).

All in all, I don't think I can make a good case for this. I'll close the issue.