Message6638

Author jeff.allen
Recipients amak, egg, fwierzbicki, jeff.allen, juneau001
Date 2011-09-04.08:46:46
SpamBayes Score 4.0850656e-13
Marked as misclassified No
Message-id <1315126007.66.0.17081011179.issue1767@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks for the razors.

>> Explicit is better than implicit.
We're dealing with a built-in where the sort criterion is implicit in Python (at the call site). The required behavour is explicit in the documentation of Python, if somewhat scattered throughout.

>> Special cases aren't special enough to break the rules.
Rare is not the same as special. It is rare that one would have a reason to define __cmp__ inconsistently with the rich comparison operations including __eq__. But Python allows for it and specifies a behaviour. I see no case that Jython sorting should, as a special case, be similar to Java sorting instead, __cmp__ being somehow analagous to implementing Comparable.

>> Although practicality beats purity.
The proposed implementation seems as practical as the existing one.

>> In the face of ambiguity, refuse the temptation to guess.
It is unambiguous that sort should be based on "less-than", so I'm calling _lt in the code. We have other possible definitions of "less-than": __lt__(), _cmp()==-1 and __cmp__()==-1. I looked at the way they delegate to each other and I'm 95% sure I chose correctly. Is there a language lawyer in the house?

Python 2.x may have departed from its own Zen in this area. Python 3.x is back on track as __cmp__ and friends are withdrawn, probably in the interests of having one obvious way to do things.

>> Is the users use case and assertion sufficient justification to modify jython?

Jython promises to implement Python (with explicit derogations concerning threads and garbage collection). Isn't Egg's application, wise or not, just the means by which we discovered Jython does not keep this promise when it comes to sorting? So it's not a special plea to change the definition of Jython, rather a bug fix.

On the downside, there would be a risk of breaking existing code, but only code that defines __cmp__ and rich comparison inconsistently (rare), and depends on the current (unintended) behaviour. Since the behaviour you get is "apparently nonsensical", I doubt anyone has done that.

So I call "do it", but I'm open to:
1. learning that delegating to _lt() was the wrong way after all; and
2. feedback on the mechanics, as I'm new to contributing patches, etc..

Jeff
History
Date User Action Args
2011-09-04 08:46:47jeff.allensetmessageid: <1315126007.66.0.17081011179.issue1767@psf.upfronthosting.co.za>
2011-09-04 08:46:47jeff.allensetrecipients: + jeff.allen, fwierzbicki, amak, juneau001, egg
2011-09-04 08:46:47jeff.allenlinkissue1767 messages
2011-09-04 08:46:46jeff.allencreate