Title: Min / Max returns different values depending on parameter order
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Calvin Davis, steven.daprano, terry.reedy
Priority: normal Keywords:

Created on 2020-07-11 04:02 by Calvin Davis, last changed 2020-07-13 05:40 by Calvin Davis. This issue is now closed.

File name Uploaded Description Edit
yqzRk0Y.png Calvin Davis, 2020-07-11 04:02 IDLE example
Messages (6)
msg373512 - (view) Author: Calvin Davis (Calvin Davis) Date: 2020-07-11 04:02
See attached image

The behavior of min() (and probably max and other related functions) changes depending on the order of the parameters it sorts.

In the image, I sorted two tuples, coordinate points, with the same Y value and different X values. When the X values were in increasing order, finding the minimum x value and minimum y value were the same. However if the list was reversed, finding the minimum x and y values in the list provided different results.
msg373513 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2020-07-11 04:16
This is correct behaviour. What makes you think otherwise?

For future bug reports, please don't post screen shots of text, copy and paste the text into the body of your bug report.

Posting screenshots makes it difficult for us to copy and run your code, and discriminates against the blind and visually impaired who may be reading this with a screen-reader, which doesn't not work with images.
msg373514 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2020-07-11 04:32
In your first example, `min([(-5, 2), (0, 2)])` the min() function compares the two tuples and finds that the first one is lexicographically smaller:

    py> (-5, 2) < (0, 2)

so (-5, 2) is considered the minimum. In the second example, using the key function compares 2 with 2, but since they are equal, the *first* tuple wins and is considered the minimum, and so using the key function doesn't change the result.

In your third example, after reversing the list, you have `min([(0, 2), (-5, 2)])` and the min() function compares the two tuples and finds the *second* tuple is the smaller:

    py> (0, 2) < (-5, 2)

But in the fourth example, using the key function, yet again the comparison compares 2 with 2 and finds them equal, and so the *first* tuple wins and (0, 2) is declared the minimum.

When using the key function, only the second item of the tuple is looked at; the first item is ignored. So the difference between 0 and -5 is irrelevant, and the tie is decided by which element was seen first.
msg373515 - (view) Author: Calvin Davis (Calvin Davis) Date: 2020-07-11 05:02
Thank you for the clarification, sorry for the report! You're awesome!
msg373582 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-07-13 03:05
Calvin, min and max are builtin functions and part of 'Interpreter Core'.  Confusing IDLE with Python is common for beginners who use IDLE.  Do you think I could reduce the confusion by somehow changing the message printed at the top of Shell, before '>>>'?
msg373585 - (view) Author: Calvin Davis (Calvin Davis) Date: 2020-07-13 05:40
You say that confusing IDLE with Python is common for beginners, do you mean to suggest that IDLE isn't a Python interpreter? I know IDLE is essentially just an IDE and distinctly different than the python shell, but I wasn't aware the differences would affect anything. I expect my sample code would work the same in IDLE or a python file, no confusion there.

I guess I'm not sure what you mean by reducing confusion, because to me IDLE and the python shell are similar enough, and both distinctly different than executing a .py file, though both should have the same behavior right?
Date User Action Args
2020-07-13 05:40:27Calvin Davissetmessages: + msg373585
2020-07-13 03:05:53terry.reedysetassignee: terry.reedy ->
messages: + msg373582
components: + Interpreter Core, - IDLE
2020-07-11 05:02:51Calvin Davissetmessages: + msg373515
2020-07-11 04:32:06steven.dapranosetmessages: + msg373514
2020-07-11 04:16:23steven.dapranosetstatus: open -> closed

nosy: + steven.daprano
messages: + msg373513

resolution: not a bug
stage: resolved
2020-07-11 04:02:02Calvin Daviscreate