2 deleted 16 characters in body edited May 30 '18 at 22:22 eyorble 6,70311 gold badge1212 silver badges3030 bronze badges As Kuba mentioned in the comments, it's coincidence that the two layered function works -- it turns out that function is equivalent to Null &. You can check this by running: Reap[SortBy[data, ((Sow[Key[#]]; Key[#]Sow[Key[#]]) &) &]]  Which will output a list containing firstly the sorted list, and secondly the list generated by the function used to sort it. In this case, that second list is {}. It turns out that by itself, Key[#] & also doesn't mean anything, but it has very different sorting characteristics. You can see that by omitting the outermost function above: Reap[SortBy[data, (Sow[Key[#]]; Key[#]Sow[Key[#]]) &]]  The second part of this output is: {Key[1/4], Key[-1/4], Key[-1/4], Key[-1/4]} Which correlates with the first element getting moved to the end in the "sorted" result. However, this is actually the same as SortBy[data, #&]. In short, with associations it appears that SortBy sorts by the function given to it first, and then by key to resolve conflicts. As such, any function that generates the same output for every member of the association should be the same as sorting by key. Perhaps counter-intuitively however, Key[#]& absolutely does not produce the same result for every element and also doesn't produce the keys of the elements. As Kuba mentioned in the comments, it's coincidence that the two layered function works -- it turns out that function is equivalent to Null &. You can check this by running: Reap[SortBy[data, ((Sow[Key[#]]; Key[#]) &) &]]  Which will output a list containing firstly the sorted list, and secondly the list generated by the function used to sort it. In this case, that second list is {}. It turns out that by itself, Key[#] & also doesn't mean anything, but it has very different sorting characteristics. You can see that by omitting the outermost function above: Reap[SortBy[data, (Sow[Key[#]]; Key[#]) &]]  The second part of this output is: {Key[1/4], Key[-1/4], Key[-1/4], Key[-1/4]} Which correlates with the first element getting moved to the end in the "sorted" result. However, this is actually the same as SortBy[data, #&]. In short, with associations it appears that SortBy sorts by the function given to it first, and then by key to resolve conflicts. As such, any function that generates the same output for every member of the association should be the same as sorting by key. Perhaps counter-intuitively however, Key[#]& absolutely does not produce the same result for every element and also doesn't produce the keys of the elements. As Kuba mentioned in the comments, it's coincidence that the two layered function works -- it turns out that function is equivalent to Null &. You can check this by running: Reap[SortBy[data, ((Sow[Key[#]]) &) &]]  Which will output a list containing firstly the sorted list, and secondly the list generated by the function used to sort it. In this case, that second list is {}. It turns out that by itself, Key[#] & also doesn't mean anything, but it has very different sorting characteristics. You can see that by omitting the outermost function above: Reap[SortBy[data, (Sow[Key[#]]) &]]  The second part of this output is: {Key[1/4], Key[-1/4], Key[-1/4], Key[-1/4]} Which correlates with the first element getting moved to the end in the "sorted" result. However, this is actually the same as SortBy[data, #&]. In short, with associations it appears that SortBy sorts by the function given to it first, and then by key to resolve conflicts. As such, any function that generates the same output for every member of the association should be the same as sorting by key. Perhaps counter-intuitively however, Key[#]& absolutely does not produce the same result for every element and also doesn't produce the keys of the elements. 1 answered May 30 '18 at 22:13 eyorble 6,70311 gold badge1212 silver badges3030 bronze badges As Kuba mentioned in the comments, it's coincidence that the two layered function works -- it turns out that function is equivalent to Null &. You can check this by running: Reap[SortBy[data, ((Sow[Key[#]]; Key[#]) &) &]]  Which will output a list containing firstly the sorted list, and secondly the list generated by the function used to sort it. In this case, that second list is {}. It turns out that by itself, Key[#] & also doesn't mean anything, but it has very different sorting characteristics. You can see that by omitting the outermost function above: Reap[SortBy[data, (Sow[Key[#]]; Key[#]) &]]  The second part of this output is: {Key[1/4], Key[-1/4], Key[-1/4], Key[-1/4]} Which correlates with the first element getting moved to the end in the "sorted" result. However, this is actually the same as SortBy[data, #&]. In short, with associations it appears that SortBy sorts by the function given to it first, and then by key to resolve conflicts. As such, any function that generates the same output for every member of the association should be the same as sorting by key. Perhaps counter-intuitively however, Key[#]& absolutely does not produce the same result for every element and also doesn't produce the keys of the elements.