Currently https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertSetEqual returns a random list, but I'd like to see it sorted for ease of reading which running tests.

Should be small, but useful.  Happy to make the edit myself, but have no clue how to send you changes.

Hi Jess, I think this could be added.

I think it should require only a a sort in https://github.com/python/cpython/blob/0f221d09cad46bee38d1b7a7822772df66c53028/Lib/unittest/case.py#L1127-L1138, to update the tests and add a blurb.

You will need to get Python source code at https://github.com/python/cpython and you can get information about how to contribute to Python in the dev guide : https://devguide.python.org/

If you need help, I would be happy to assist you and to review your pull request.

If you don't have time to work on this issue, I think we could keep it for the next mentored sprint.

Wow!  Thank you, very fast and the precise snippet of info I needed.  Will try to send something off today.  Very exciting.

> I think it should require only a a sort 

It's possible to have non-sortable elements in the set, so you'll either need to sort on the repr of the elements or have a fallback:

    assertSetEqual({10, None, 'abc'}, {20, 3+4j, 10})

Just to be clear, as Raymond said, when we have two non-sortable objects (for instance, two instances which their class didn't implement the __lt__ and __gt__ methods), we should compare their repr() without sort() like now.

@rhettinger
> It's possible to have non-sortable elements in the set, so you'll either need to sort on the repr of the elements or have a fallback

Yes, it is the repr that is used in the loop and that what's the sorting needs to be done against.


@Windson Yang
> we should compare their repr() without sort() like now.

I'm not sure to understand, can you provide more information about what you are thinking of?

Is there a reason to add 2.7, 3.4, 3.5, 3.6 and 3.7 to versions affected ?

As far as I can tell, this is a new feature and should only go in 3.8.

My point is careful about the non-sortable object. My mistake, this should be an enhancement, not a bug.

Good call on the repr(), hadn't noted the "3+4j" issue - __gt__ and __lt__ do work for compare there, but not sorted().  *shrug*  Will make sure the solution takes that into account in some fashion.

Bit slower as I expected as setting up the windows env has some bits that are not entirely happy.

Hi Jess, are you still working on this?