Something to keep in mind:
the math module is written in C, and will remain that way for the time being (see recent discussion on, I think, this list and also the discussion when we added math.isclose()
which means it will be for floats only.
My first thought is that not every one line function needs to be in the standard library. However, as this thread shows, there are some complications to be considered, so maybe it does make sense to have them hashed out.
Regarding NaN:
In [4]: nan = float('nan')
In [6]: nan > 5
Out[6]: False
In [7]: 5 > nan
Out[7]: False
This follows the IEEE spec -- so the only correct result from
clip(x, float('nan')) is NaN.
Steven D'Aprano wrote:
I don't care too much whether the parameters are mandatory or have
defaults, so long as it is *possible* to pass something for the lower
and upper bounds which mean "unbounded".
I think the point was that if one of the liimts in unbounded, then you can jsut use min or max...
though I think I agree -- you may have code where the limits are sometimes unbounded, and sometimes not -- nice to have a way to have only one code path.
(1) Explicitly pass -INFINITY or +INFINITY as needed;
but which
that's it then.
infinity, float or Decimal? If you pass the wrong one, you may have to
pay the cost of converting your values to float/Decimal, which could end
up expensive if you have a lot of them.
well, as above, if it's in the math module, it's only float.... you could add one ot the Decimal module, too, I suppose.
(2) Pass a NAN as the bounds. With my implementation, that actually
works! But it's a surprising accident of implementation, it feels wrong
and looks weird,
and violates IEEE754 -- don't do that.
(3) Use some special Infimum and Supremum objects which are smaller
than, and greater than, every other value. But we don't have such
objects, so you'd need to create your own.
that's what float('inf') already is -- let's use them.
(4) Use None as a placeholder for "no limit". That's my preferred
option.
reasonable enough -- and would make the API a bit easier -- both for matching different types, and because there is no literal or pre-existing object for Inf.
-Chris