Was: Is this an Bug in python 2.3?? Reflective relational operators

[Balaji]

Dear Jeff,

Thanks for your reply. I see that the PEP and the current docs
specify that __ge__ and __le__ are their own reflection.

Given that PEP 207 proposes rich comparison to handle cases
(brought upon by NumPy) where the objects returned should not be
assumed to be boolean, what is the argument for automatic reflection?

Automatic reflection prevents the resulting objects from being
dependant on the ordering of the arguments to __ge__ and __le__. In
our application, this ordering is important.

Can anyone think of a way to get around automatic reflection of
relational operators?

TIA,
Balaji.

 

[Dieter Maurer]

Thanks for your reply. I see that the PEP and the current docs
specify that __ge__ and __le__ are their own reflection.
...
Automatic reflection prevents the resulting objects from being
dependant on the ordering of the arguments to __ge__ and __le__. In
our application, this ordering is important.

? The order of "__ge__" and "__le__" operands is always important -- not
only in your application...

I read the documentation as "__le__" is the reflection of "__ge__" and vice
versa. This seems to be senseful.

Can anyone think of a way to get around automatic reflection of
relational operators?

Define the respected operators for both operands. Then, there is no
need for reflection.

Dieter

 

[Balaji]

Hello Everybody...

Let me try to explain what do I mean by "ordering importance".

In our application a expression 100>=x reads as 100 is an upper bound
on x. Mathematically it is same as saying x<=100 which also bounds x
by 100. But in modelling, the user wants to preserve the order in
which he has written the expression.

If the left side of an operand is an immutable type then this ordering
is no longer preserved, even if both the methods are implemented(i.e
__le__ and __ge__).

__radd__ allows you to have an immutable type on the left side. An
__rge__ method would provide the same functionality for relational
operators.

Is there a way to obtain this behavior with current syntax?

Regards

Balaji

 

[Balaji]

Hello Everybody...

Here is a code (tested)

class Test:

def __le__(self,other):
print " <= "
def __ge__(self,other):
print " >= "
def __add__(self,other):
print " + "
def __radd__(self,other):
print " r+ "


Suppose s is an instance of Test.

s=Test()

s>=100

prints >=

but 100>=s

prints <=

The point here is mathematically it is right but not modelling wise.

By modelling I mean, the user wants to preserve the order in which he
typed the
expression.

Is there a way to obtain the radd behavior in __ge__ and __le__ with
current syntax..

Regards

Balaji

 

[=?ISO-8859-1?Q?Gr=E9goire_Dooms?=]

Hello Everybody...

Let me try to explain what do I mean by "ordering importance".

In our application a expression 100>=x reads as 100 is an upper bound
on x. Mathematically it is same as saying x<=100 which also bounds x
by 100. But in modelling, the user wants to preserve the order in
which he has written the expression.

If the left side of an operand is an immutable type then this ordering
is no longer preserved, even if both the methods are implemented(i.e
__le__ and __ge__).

No, as far as I understand the doc, if the left side does not support
comparing to your instance on the left then your instance's reversed
operator method is called.

__radd__ allows you to have an immutable type on the left side. An
__rge__ method would provide the same functionality for relational
operators.

Is there a way to obtain this behavior with current syntax?

I far as I know, there is no __rge__ and no possible way to detect if
ian op was called from either syntax.
The comparison operators should be used in cases where the "reflective"
behaviour is sound. I beleive they should not be used for other things
than comparing instances for witch there is a complete order (many
others will disagree).

 

[Leo]

The comparison operators should be used in cases where the "reflective"

behaviour is sound. I beleive they should not be used for other things
than comparing instances for witch there is a complete order (many
others will disagree).

I don't immediately see why we should restrict the usage of comparison
operators to that case, but that doesn't matter. What (maybe) matters
is: If we were to ask (PEP) for an __rge__ with a default
implementation that calls __le__ with the parameters inverted, would
that break anything?

I can think of other applications where this would be useful. For
example: generating MathML from python expressions. Or looking at it
another way, wouldn't it improve language consistency to add an
__rge__ method?

Unfortunately in PEP 207 the issue of reflexivity is raised and
decided, but not justified. Maybe at the time no one had an example
where this feature would be useful? Would it be too hard to change?

Thx,
Leo.

 

[Dan Bishop]

Hello Everybody...

[against Python's automatic reflection of comparison operators]

By modelling I mean, the user wants to preserve the order in which he
typed the expression.

Why not preserve the original text of the expression?

What exactly are you trying to do?

 

[Dieter Maurer]

...
In our application a expression 100>=x reads as 100 is an upper bound
on x. Mathematically it is same as saying x<=100 which also bounds x
by 100. But in modelling, the user wants to preserve the order in
which he has written the expression.

Python's "rich comparison" methods have been defined for
comparisons and not for modelling. For any senseful definition
of ">=" and "<=", "x >= y" is equivalent to "y <= x".

As you seem to be interested in modeling and not in comparisons,
you must use your mapping of abstract syntax to objects
and can not use Python's default one.

The "ast" modul contains necessary prerequisites to implement
such a mapping. Recently, I found an example in Zope's
"RestrictedPython".


Dieter

 

[Balaji]

Dear Dan,

What I'm trying to do in my application is preserve the order in which
the user wrote an expression.

If a user writes e1=100>=x, python treats it as e1= x<=100. Both are
same mathematically but semantically they are not. If a user prints
this expression he will get e1= x<=100, which is different than
e1=100<=x.

In my application both the <= and >= have totally different meaning.
They are not just used for comparisson.

Regards

Balaji

 

[Balaji]

Dear Dan,

What I'm trying to do in my application is preserve the order in which
the user wrote an expression.

If a user writes e1=100>=x, python treats it as e1= x<=100. Both are
same mathematically but semantically they are not. If a user prints
this expression he will get e1= x<=100, which is different than
e1=100<=x.

In my application both the <= and >= have totally different meaning.
They are not just used for comparisson.

Regards

Balaji