[Python-bugs-list] [ python-Feature Requests-444984 ] Type comparison
SourceForge.net
noreply@sourceforge.net
Sat, 28 Jun 2003 00:23:46 -0700
Feature Requests item #444984, was opened at 2001-07-26 18:38
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444984&group_id=5470
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Kirill Simonov (kirill_simonov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Type comparison
Initial Comment:
1. Let X and Y be classes or types. Currently
(X <= Y) == (id(X) <= id(Y)).
It would be more useful if
(X <= Y) == issubclass(Y, X)
Unresolved issue:
cmp(X, Y) == ???
2. Similar proposition for classes and instances:
(x in X) == isinstance(x, X)
3. Proposition for Python 3.0:
1 < "1" ==> Exception
----------------------------------------------------------------------
>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 02:23
Message:
Logged In: YES
user_id=80475
Closing this one because subclass relationships (even taking
into account mro) establish an ordering relation only for
classes in the same family.
It was a nice thought though.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 19:43
Message:
Logged In: YES
user_id=357491
But you used issubclass quite well for your need. Is this really worth
complicating the comparison code? If you could write a patch to implement
this you might be able to get it applied.
As for the Python 3 proposition, there has been a discussion of having
comparisons like that fail or always return false when the types are different.
----------------------------------------------------------------------
Comment By: Gregory Smith (gregsmith)
Date: 2001-09-18 13:40
Message:
Logged In: YES
user_id=292741
Regarding (1); this is an interesting proposal,
the idea is to guarantee that classes sort in such an order
that base classes precede the subclasses. A problem here,
is that the comparison must have a commutative and
transitive property, or it could break all kinds of things; so you
need to do something like:
X<Y: if X is a subclass of Y , then X>Y
if Y is a subclass of X , then Y>X
otherwise, compare id(X), id(Y)
The problem is that if A is a subclass of B,
X is a subclass of Y, then A>B, X>Y;
but if it turns out that B>X because
id(B) > id(X), you would need A>X, A>Y,B>Y
to guarantee the transitive property. What I've
defined above doesn't do that. Rather a
challenge to define a transitive compare
with this property. Is it worth it when you
already have the issubclass() ?
cmp(X,Y) is defined if X<Y and X==Y etc are defined.
I don't see what's unresolved.
(2) no comment, except that it extends the definition
of 'in' to a new and quite different meaning.
(3) needs more definition. This, I think, comes down
to the same issue as (1); if you are thinking that ideally
1<"2" should be true and 2<"10" should be
true and 4<"1" should be false, and that the
exception should be raised to warn you that this isn't
happening, I would point out that such an
ordering would again be (probably) impractical to
define as being transitive. In any case, "10"<"2"
and you don't want to change that (if you
do, check out my new project 'numacomp').
The current '<' comparison
is designed in such a way that ANY object
can be compared to ANY other object and
the results are transitive and commutative,
if totally arbitrary in many cases.
If you can't do that with any two objects,
then you can't always compare lists or tuples
(which is done by comparing each member in
sequence). And then where are you?
Often you need the < operator ONLY so you
can sort things, in which case it has to
be defined and transitive, but the quirks
don't matter. So it should remain legal to
compare anything to anything.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=444984&group_id=5470