I'm -1 on this patch.  At first blush it would seem nice to progagate sort's notion of a key= function; however, sort() is an all at once operation that can guarantee the function gets called only once per key.  In contrast, bisect() is more granualar so consecutive calls may need to invoke the same key= function again and again.  This is almost always the the-wrong-way-to-do-it (the key function should be precomputed and either stored separately or follow a decorate-sort pattern).  By including custom sorting in bisect's API we would be diverting users away from better approaches.

A better idea would be to create a recipe for a SortedList class that performed pre-calculated custom keys upon insertion and maintained an internal, decorated list.