Forgetting "()" when calling methods

[Tim Peters]

[Tim]
>> No, the current state makes no sense ... [and] ...is an inconsistent
>> mish-mash

[Terry Reedy]
> OK, we agree on that.  It a result of various local optimazations and
> compromises

It's really the result of Guido changing his mind about whether comparisons
should be allowed to raise exceptions.

> and needs ground up redesign.

Probably, yes.

> My point in relation to () is that I would hate to see a similar
> mishmash created in relation to truth values, especially not for the
> local optimazation of allowing people to forget to type '()' in boolean
> context.

> ...

> The question is whether .sort() should come with at least an option to
> work with a heterogenous items and not raise an exception -- without
> the user having to write a custom order function  -- so programmers who
> know what they are doing when trying to sort such a list can do so
> nearly as easily as they used to.

Without compelling concrete use cases, that's unlikely to happen.  The use
cases are needed to flesh out what guarantees are *expected* of a "senseless
sort".  Presumably proponents want something more than "don't care -- make
up anything at all", else they wouldn't be sorting to begin with <wink>.

I'm personally unhappy with ordering results that aren't guaranteed
consistent across platforms, program runs, and Python releases.  So, e.g.,
the result of

class C:
    pass
a = C()
b = C()
print a < b

today flunks all those criteria.  Comparing complex numbers
lexicographically passes them (so, IMO, default instance comparison (which
is by memory address) is much more mysterious and dangerous than the way
Python used to compare complex numbers -- "dangerous" refers to that
persistent database systems like ZODB using BTree-based data structures act
insanely when objects end up getting compared by accidents of memory address
(ZODB users would be much better off if Python complained whenever an
ill-defined (by the criteria above) compare was requested)).