[Python-ideas] Re: giving set.add a return value

2020-07-06 Thread Chris Angelico
On Tue, Jul 7, 2020 at 12:53 PM Stephen J. Turnbull wrote: > > Christopher Barker writes: > > > I meant in the context of putting things in, or testing whether they are > > in, sets. Not in any other context. > > OK, but restricting context that way is asking for eventual trouble, > because ther

[Python-ideas] Re: giving set.add a return value

2020-07-06 Thread Stephen J. Turnbull
Christopher Barker writes: > I meant in the context of putting things in, or testing whether they are > in, sets. Not in any other context. OK, but restricting context that way is asking for eventual trouble, because there's one more thing you can do with sets: get stuff out of them (by iterati

[Python-ideas] Re: Add builtin function for min(max())

2020-07-06 Thread Steven D'Aprano
On Mon, Jul 06, 2020 at 10:46:03AM -0700, Christopher Barker wrote: > 1) The math module is written in C, and Guido at least (he was still BDFL > then) rejected the idea of refactoring it to allow Python components (yes, > that was proposed, and even started by, I think, Victor Stiner). Yes, you >

[Python-ideas] Re: Add builtin function for min(max())

2020-07-06 Thread Rob Cliffe via Python-ideas
On 06/07/2020 01:59, Greg Ewing wrote: If one of the bounds is missing, you don't need clamp(), you can use min() or max(). Not true. It would be true if you knew a specific one of the bounds was always missing, but you might want to call it repeatedly, sometimes with either bound (or bot

[Python-ideas] Re: Add builtin function for min(max())

2020-07-06 Thread Christopher Barker
On Mon, Jul 6, 2020 at 11:28 AM Chris Angelico wrote: > On Tue, Jul 7, 2020 at 3:49 AM Christopher Barker > wrote: > > > > [*] Honestly, while you *could* use clamp() with any comparable objects, > I really don't see a use case for anything non-numerical, but why not? > > Depends how broadly you

[Python-ideas] Re: Add builtin function for min(max())

2020-07-06 Thread Chris Angelico
On Tue, Jul 7, 2020 at 3:49 AM Christopher Barker wrote: > > [*] Honestly, while you *could* use clamp() with any comparable objects, I > really don't see a use case for anything non-numerical, but why not? > Depends how broadly you define "numerical". Is a datetime numerical? It's a reasonable

[Python-ideas] Re: Best approach for opaque PyObject

2020-07-06 Thread William Pickard
If we do go with sending methods like Py_TYPE to be exported from pythoncore, every extension (even first party ones) will end up requiring import and call overhead. The can get noisy and costly REAL FAST. Py_VISIT is a supreme example of this problem as it can noisily fill a stack trace. __

[Python-ideas] Re: Add builtin function for min(max())

2020-07-06 Thread Christopher Barker
While I agree that having "clamp" operate on all Python types is a "good thing"[*], there is a complication. If it were put in the math module, then it would pretty much have to be a floating point function. At least that was the case for math.isclose(). My first prototype of isclose() was written

[Python-ideas] Re: Add builtin function for min(max())

2020-07-06 Thread Bruce Leban
On Mon, Jul 6, 2020 at 4:27 AM Richard Damon wrote: > > > Supported, yes. Recommended, no. IEEE-754 specifies that the *minimum > > *operation propagates NaNs while the /alternate /*minimumNumber > > *operation drops NaNs. > > It should be noted, this is a change in the Standard that is just 1 ye

[Python-ideas] Re: Add builtin function for min(max())

2020-07-06 Thread Richard Damon
On 7/5/20 11:07 PM, Bruce Leban wrote: > > On Sun, Jul 5, 2020 at 5:49 PM Steven D'Aprano > wrote: > > On Sun, Jul 05, 2020 at 11:58:58AM -0700, Bruce Leban wrote: > > But using a NAN is not an unreasonable operation. > > > I didn't say that it was. A NaN is the

[Python-ideas] Re: Add builtin function for min(max())

2020-07-06 Thread Federico Salerno
On 05/07/2020 23:55, Rob Cliffe wrote: I think None should be allowed as a missing bound. +1 I don't think the new function should be restricted to numbers.  There may be uses for strings, or for user-built classes; why restrict it unnecessarily? If it quacks like supporting __lt__ and __gt__