This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: incomplete numerical comparisons
Type: Stage:
Components: Interpreter Core Versions: Python 2.5
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: doko, mark.dickinson, rhettinger
Priority: high Keywords:

Created on 2007-01-12 00:18 by doko, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg30988 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2007-01-12 00:18
[forwarded from http://bugs.debian.org/334022]

bug submitter writes:

I've been tracking down the regression failure in python-pgsql under
python2.[45], and here's what it comes down to.

Python-pgsql includes a short int type named PgInt2, which allows itself
to be coerced into all of the usual numeric types.

The regression that fails is when a PgInt2 is compared with a float.  In
this case python determines that the comparison is not implemented.

The problem is this:

- Under python2.[45], the float type includes tp_richcompare but not
  tp_compare.

- When calling try_rich_to_3way_compare(), python does not try any kind
  of numeric coercion, and so the comparison fails.

- When calling try_3way_compare(), python successfully coerces the
  PgInt2 into a float, but then the comparison fails because the float
  type has no tp_compare routine.

Presumably what would fix things would be one of the following:

- Bring back the trivial float_compare() routine, which was removed with
  python2.[45] when they brought in the new float_richcompare() instead;

- In try_3way_compare(), if the coercion succeeds and neither object
  has a tp_compare routine, try tp_richcompare before failing completely.

Does either of these solutions seem feasible?

Thanks - Ben.
msg30989 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-04-11 16:55
Raising the priority so this report doesn't get lost.
msg81647 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-11 15:04
This issue is out of date from the perspective of python-pgsql, since
that's long been fixed.

It's difficult to figure out exactly what the issue is here.  As best as
I can guess, it's something like the following.  After:

class MyInt(object):
    def __init__(self, n):
        self.n = n

    def __coerce__(self, other):
        if type(other) is float:
            return float(self.n), other

x = MyInt(3)

the comparison "x < 4.0" gives False in the 2.4+, and True in 2.3.

I'm closing this as a won't fix:  it doesn't seem worth changing the
comparison behaviour for Python 2.7 (which may well be the last in the
line of 2.x releases anyway), and the whole
coercion/three-way-comparison mess is gone in 3.x.
History
Date User Action Args
2022-04-11 14:56:22adminsetgithub: 44445
2009-02-11 15:04:17mark.dickinsonsetstatus: open -> closed
resolution: wont fix
messages: + msg81647
2009-02-10 19:56:32mark.dickinsonsetassignee: mark.dickinson
2009-02-10 18:13:10ajaksu2setnosy: + mark.dickinson
2007-01-12 00:18:26dokocreate