This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients mark.dickinson, serhiy.storchaka
Date 2018-02-08.19:25:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1518117933.61.0.467229070634.issue32794@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2018-02-08 19:25:33mark.dickinsonsetrecipients: + mark.dickinson, serhiy.storchaka
2018-02-08 19:25:33mark.dickinsonsetmessageid: <1518117933.61.0.467229070634.issue32794@psf.upfronthosting.co.za>
2018-02-08 19:25:33mark.dickinsonlinkissue32794 messages
2018-02-08 19:25:33mark.dickinsoncreate