Forgetting "()" when calling methods

[Gareth McCaughan]

Alex Martelli wrote:

[Tim Peters:]
> > OTOH, how many would have scored 100% if also asked what the result of
> > sorting would be?  I'm not sure anyone could have.  For years, ints came
> > out "less than" lists, which in turn came out "less than" longs, so that
> > 
> >     [10, [9], 7L, 8]
> > 
> > was considered to be "in sorted order" as-is.  It was something like 7
> > years before someone finally noticed how nuts that was.

[Alex:]
> *Blink* -- I don't get it.  Even if int < list < long, how CAN the
> two int's here be ``considered in sorted order''???

a0 <= a1 <= ... <= a(n-1). The old ordering wasn't
transitive. That was indeed nuts, of course.

> Here is a typical use case: prettyprinting a dictionary.
...
> Oops!  We can't prettyprint it any more -- kaBOOM.
...
> However, it seems totally arbitrary to me that the standard
> library's pprint.pprint should raise an exception just because 
> the user's trying to prettyprint a dictionary with some complex
> numbers as keys.  I guess one could class this as a bug in
> pprint, but from my POV what it does is highlight a typical
> case in which the inability to ask "just sort this stuff so
> it displays in an order that doesn't appear totally random"
> *hurts*, and hurts pretty badly too.
> 
> What's the ADVANTAGE gained, worth breaking prettyprinting for?
> 
> It seems to me it's basically one of "purity" -- that 1.5.2
> was far more pragmatic in this regard.  I know I'm not gonna get
> the pragmatism back, sigh, but is it SO hard to understand why
> I would want it?!

Hear, hear. The decision to make comparing complex numbers
throw an exception never made sense to me. (And I'm a
mathematician; believe me, I understand the appeal of
purity.)

Here's another example: regression testing. For that,
you want a sort order that's guaranteed not to change
across runs either, though it's probably OK if it
changes with new versions of Python.

The key question, to which I've never seen a convincing
answer, is threefold:

  1 What can you do more easily in Python as a result
    of complex comparisons throwing exceptions?

  2 What actual bugs are prevented by having complex
    comparisons throw exceptions?

  3 How is Python made easier to learn or understand
    by having complex comparisons throw exceptions?

It seems to me that the answers are "nothing", "none"
and "it isn't", respectively. I'm open to persuasion.

-- 
Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc