classification
Title: Add clamp() function to builtins
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: BTaskaya, TheComet, mark.dickinson, steven.daprano
Priority: normal Keywords:

Created on 2019-05-03 21:50 by TheComet, last changed 2020-07-28 07:35 by mark.dickinson. This issue is now closed.

Messages (7)
msg341358 - (view) Author: TheComet (TheComet) Date: 2019-05-03 21:50
It would be nice to have a clamp() builtin in addition to min() and max() so one can type e.g. "clamp(value, 2, 5)" instead of having to type "min(max(value, 5), 2)".
msg341359 - (view) Author: TheComet (TheComet) Date: 2019-05-03 21:56
I have implemented it on my branch here: https://github.com/TheComet/cpython/blob/fix-issue-36788/Python/bltinmodule.c

It still needs further testing and I haven't leak checked it properly.
msg341361 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2019-05-03 22:32
I doubt this is important enough to go into builtins, the only practical use-case I know of for this function is with numbers, so this could go in the math module.

But putting that aside, there are some other problems:

- it isn't clear that clamp() is meaningful for anything that could possibly need a key function;

- the behaviour you have for iterable arguments is inconsistent with the existing behaviour of min(max(x, a), b):

min(max('a string', 'd'), 'm')
=> returns 'd' not ['d', 'd', 'm', 'm', 'm', 'i', 'm', 'g']

- your iterable behaviour is easily done with a comprehension and doesn't need to be supported by the function itself

[clamp(x, a, b) for x in values]

- what do you intend clamp() to do with NAN arguments?

- for numbers, it is sometimes useful to do one-sided clamping, e.g. clamp(x, -1, ∞).

You should read over this thread here:

https://mail.python.org/pipermail/python-ideas/2016-July/041262.html
msg358780 - (view) Author: Batuhan Taskaya (BTaskaya) * (Python committer) Date: 2019-12-21 19:06
Should this issue stay? Maybe port this discussion over python-ideas and after the resolution open it again?
msg358789 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2019-12-22 10:24
> Maybe port this discussion over python-ideas and after the resolution open it again?

Sounds good to me. Adding a new builtin function is a big deal that would likely need a PEP. I'm not keen on adding something like this to the math module, either, when it's so simple to construct from max and min.

Closing as rejected here; it can be re-opened if there's a strong consensus for adding it on the ideas list.
msg374473 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2020-07-28 07:31
#41408 was closed as a duplicate of this issue

See also the recent discussion on python-ideas at https://mail.python.org/archives/list/python-ideas@python.org/thread/KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS/#KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS

That discussion has petered out without a clear consensus. The next step would likely be for an interested party to put together a PEP.
msg374474 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2020-07-28 07:35
Another python-ideas thread, from 2016: https://mail.python.org/archives/list/python-ideas@python.org/thread/EHZAXE4P2VOT3CE4H6SNDPDASW7H2CGS/
History
Date User Action Args
2020-07-28 07:35:51mark.dickinsonsetmessages: + msg374474
2020-07-28 07:32:49mark.dickinsonlinkissue41408 superseder
2020-07-28 07:31:52mark.dickinsonsetmessages: + msg374473
2019-12-22 10:24:44mark.dickinsonsetstatus: open -> closed

nosy: + mark.dickinson
messages: + msg358789

resolution: rejected
stage: resolved
2019-12-21 19:06:51BTaskayasetnosy: + BTaskaya
messages: + msg358780
2019-05-11 02:18:21terry.reedysetversions: + Python 3.8
2019-05-03 22:32:38steven.dapranosetnosy: + steven.daprano
messages: + msg341361
2019-05-03 21:56:59TheCometsetmessages: + msg341359
2019-05-03 21:50:00TheCometcreate