'1' + 1 ==> True ???

[Nicola Mingotti]

Hi ,

I obtained this result :
------

'1' > 1 True
------
with python2.2.3 and 2.3.3 .
(Yes , in python 2.2 i get 1 instead of True)

but
------ '1' + 1 TypeError
-------

and
-----------------------------'1'.__gt__._ _doc__

'x.__gt__(y) <==> x>y'
-----------------------------

so i'm a little puzzled :)

Is this a bug or is there a very good reason
to this strange behaviour ?

Thank you all .

bye .

(Please forgive english mistakes)

[Ben Finney]

On Thu, 18 Mar 2004 03:45:56 +0100, Nicola Mingotti wrote:

I obtained this result :
------

'1' > 1 True
------
with python2.2.3 and 2.3.3 .
(Yes , in python 2.2 i get 1 instead of True)
This should not be surprising; the values are different, so one will be
"greater than" the other; but comparing them is not of much use.
but
------ '1' + 1 TypeError
-------
This, too, should not be surprising. Adding a character and a number
has no unambiguously correct meaning.
and
-----------------------------'1'.__gt__. __doc__

'x.__gt__(y) <==> x>y'
-----------------------------

Showing that the comparison is pretty much what you'd expect. Again,
though, the result of comparing different types like character and
integer isn't particularly useful.
so i'm a little puzzled :)

Is this a bug or is there a very good reason to this strange behaviour

What behaviour did you expect? Without knowing that it's hard to
explain why the reality is different.

--
\ "Judge: A law student who marks his own papers." -- Henry L. |
`\ Mencken |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Erik Max Francis]

Nicola Mingotti wrote:

I obtained this result :
------

'1' > 1 True
------
with python2.2.3 and 2.3.3 .
(Yes , in python 2.2 i get 1 instead of True)
Yes, with the exception of complex numbers, doing comparisons between
objects of different types is valid. The ordering is guaranteed to be
consistent on a particular implementation (e.g., here strings are
considered greater than ints). but you're not guaranteed the behavior
will be the same from implementation to implementation (i.e., it's
perfectly valid for another implementation to consider ints less than
strings).
but
------ '1' + 1 TypeError
-------
That's right, adding strings and integers is a type error because it
doesn't make any sense in Python. Python is strongly typed, so it's
unclear what this operation would mean. Do you mean int('1') + 1 or '1'
+ str(1)?
and
-----------------------------'1'.__gt__._ _doc__

'x.__gt__(y) <==> x>y'
-----------------------------

I don't understand what bearing this snippet has on the previous two.
so i'm a little puzzled :)

Is this a bug or is there a very good reason
to this strange behaviour ?

In a strongly, dynamically typed language like Python, it's helpful to
have relational operators usually work even between objects of different
types, even if the result is not immediately useful, because you often
don't know the type of an object you have and so can't guarantee that
you'll always be comparing apples with apples.

There are other approaches, such as restricting the standard relational
operators to only work with objects of the same type and raise
TypeErrors otherwise, and introduce a new set of relational operators
which are forgiving with respect to incompatible objects of different
types (this is something I did with a project of mine, where `eq'
requires type compatibility (and raises if it is not satisfied) but
`seq' ("safe equality") simply returns false instead of raising an error
with incompatible types. However, this is not the approach that Python
has historically used.

Additionally, since types determine the behavior of operations in a
strongly-typed language like Python, not operations, it's useful for
operations that have multiple meanings (+ can mean arithmetic addition
but also string concatenation) -- possible in a strongly-typed language
-- to reject ambiguous arguments rather than trying to guess what it is
you mean.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Does the true light / Of love come in flashes
-- Sandra St. Victor

[Nicola Mingotti]

On Thu, 18 Mar 2004 13:24:14 +1050, Ben Finney wrote:

On Thu, 18 Mar 2004 03:45:56 +0100, Nicola Mingotti wrote:

I obtained this result :
------

> '1' > 1 True
------ This should not be surprising; the values are different, so one will be
"greater than" the other; but comparing them is not of much use.
Here i expect "Undefined Operation" or, if this is defined,
this means that '1' and 1 are comparable so, either 1 is
seen as string or '1' is seen as a number . But ....

-----------------

> '1' + 1

TypeError
-------
With this result i see that none of the two before mentioned possibility
is possible because, in the first case i would expect ,as result, '11' and
, in the second, i would expect a number . I obtain TypeError so , i think
this is illogical .

This, too, should not be surprising. Adding a character and a number
has no unambiguously correct meaning. Also comparing a string and a character hasn't unambiguos meaning ,
has it ?

-----------------------------

>'1'.__gt__ .__doc__

'x.__gt__(y) <==> x>y'
-----------------------------

Showing that the comparison is pretty much what you'd expect. Again,
though, the result of comparing different types like character and
integer isn't particularly useful.

Here i would expect the definition of '>' between strings .
And the definition of '>' between 'chars' and 'integers' given
that a strange result has been returned .
I know python is growing and free so i don't expect that everything
is documented or everything is correct and that is the reason i asked here.

What behaviour did you expect? Without knowing that it's hard to
explain why the reality is different.

i imagined two possibility :

1) Like CommmonLisp (clisp implementation) -----> A Strinct Type Error
[1]> (> "1" 1)
*** - >: "1" is not a REAL
2) Like C -----> Char is converted to int
#include<stdio. h>
int main(){
printf("%i %i", '1' > 1 , '1' + 1 );
return 0;
}
==> 1 50
Bye .

Excuse me again for mistakes or possible (but unwanted)
rude language .

[Nicola Mingotti]

On Wed, 17 Mar 2004 19:22:26 -0800, Erik Max Francis wrote:

------

>>> '1' > 1 True
------ Yes, with the exception of complex numbers, doing comparisons between
objects of different types is valid. The ordering is guaranteed to be
consistent on a particular implementation (e.g., here strings are
considered greater than ints). ...

This is all what i wanted to know .
Even if i can't see it's utility , at least
for the behaviour of the comparison between strings
and numbers with every string considered greater of every int .

-----------------------------

>>>'1'.__gt__._ _doc__

'x.__gt__(y) <==> x>y'
-----------------------------

I don't understand what bearing this snippet has on the previous two.

Here i was looking for what you told me , so something like :
x.__gt__(y) <==> x>y if x and y are numeric object ,
every string is greater than every number (ErrorObject ,
user define class ... ??) ...
.... may be one day i could add it myself ... ;)

Thank you very much for you help .

Bye .

[Ben Finney]

On Thu, 18 Mar 2004 05:24:26 +0100, Nicola Mingotti wrote:

On Thu, 18 Mar 2004 13:24:14 +1050, Ben Finney wrote:

On Thu, 18 Mar 2004 03:45:56 +0100, Nicola Mingotti wrote:

>> '1' > 1
True

This should not be surprising; the values are different, so one will
be "greater than" the other; but comparing them is not of much use.
Here i expect "Undefined Operation"

It is defined, as you saw from inspecting the '1'.__gt__ attribute.
or, if this is defined, this means that '1' and 1 are comparable
Yes. They're stored in the computer, they have different values, those
values are scalars and thus comparable.
so, either 1 is seen as string or '1' is seen as a number
Neither of those is the case. The string is a string; the number is a
number.

Type conversion when a comparison is done is not necessary, and isn't
done. The values are compared, not converted.

>> '1' + 1
TypeError
With this result i see that none of the two before mentioned
possibility is possible because, in the first case i would expect ,as
result, '11' and , in the second, i would expect a number .

Hopefully my explanation shows why addition gives a TypeError while
comparison does not.

Where comparison is possible and unambiguous between values, it's
permitted.

Where addition is possible and unambiguous between values, it's
permitted.
I obtain TypeError so , i think this is illogical .
I hope my explanation makes the logic clearer.

This, too, should not be surprising. Adding a character and a number
has no unambiguously correct meaning.

Also comparing a string and a character hasn't unambiguos meaning ,
has it ?

Yes: "compare the values as stored in the interpreter". Not a
particularly useful thing to do, but harmless and unambiguous.

>>'1'.__gt_ _.__doc__
'x.__gt__(y) <==> x>y'

Showing that the comparison is pretty much what you'd expect. Again,
though, the result of comparing different types like character and
integer isn't particularly useful.

Here i would expect the definition of '>' between strings .

You've got the definition: "compare the values, return True if x is
greater". There's no need for a string to have its own special
definition, different from other scalars.
And the definition of '>' between 'chars' and 'integers'
A "char" is no different from a string in Python.
given that a strange result has been returned .
What's the strange result, though? One value is greater than the other;
you tested to see which one. The result is either True or False;
neither of those is strange.
I know python is growing and free so i don't expect that everything is
documented or everything is correct and that is the reason i asked
here.
You did the right thing; I hope you're gaining the realisation that
Python isn't doing anything strange or wrong in this case.

What behaviour did you expect?

i imagined two possibility :

1) Like CommmonLisp (clisp implementation) -----> A Strinct Type Error
[1]> (> "1" 1)
*** - >: "1" is not a REAL

Lisp is extremely restrictive of what can be compared with its '>'
operator:
( > "A" "B" ) *** - argument to > should be a real number: "A"

Python allows comparison of any scalar type; whether that's useful or
not is up to the programmer to decide.
2) Like C -----> Char is converted to int
#include<stdio. h>
int main(){
printf("%i %i", '1' > 1 , '1' + 1 );
return 0;
}
==> 1 50
With Python's comparison operators, no conversion needs to happen. The
interpreter has values stored; those values are scalars. If they
differ, one will be greater than the other. That fact can be queried
with the comparison operators. No type conversion needs to occur.

As pointed out in another post, the uselessness of comparing strings and
integers is compounded by the fact that there's no guarantee the same
result will occur on different machines, or different Python
implementations .

Since it doesn't break anything, though, I don't see why Python
shouldn't allow you to do it. Nor do I see why it should be converting
values between types to do comparisons.
Excuse me again for mistakes or possible (but unwanted) rude language

No rude language detected in this or your previous post.

--
\ "I went to a museum where all the artwork was done by children. |
`\ They had all the paintings up on refrigerators." -- Steven |
_o__) Wright |
Ben Finney <http://bignose.squidly .org/>

[Erik Max Francis]

Nicola Mingotti wrote:

Here i was looking for what you told me , so something like :
x.__gt__(y) <==> x>y if x and y are numeric object ,
every string is greater than every number (ErrorObject ,
user define class ... ??) ...

You're guaranteed there will be some ordering between types, but you
don't know what it is, and it might vary from implementation to
implementation. That is, for example, on a given implementation, either
all strs will be greater than ints, or all ints will be greater than
strs, but you shouldn't rely on either behavior.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ The color is red / Under my shoe
-- Neneh Cherry

[Donn Cave]

Quoth Nicola Mingotti <bl*@libero.it> :
....
| Even if i can't see it's utility ,

My guess is that the most important benefit is that any list
of Python objects can be sorted.

Donn Cave, do**@drizzle.co m

[Nicola Mingotti]

On Thu, 18 Mar 2004 05:50:33 +0000, Donn Cave wrote:

My guess is that the most important benefit is that any list
of Python objects can be sorted.

OH , YES !!
This is a sufficient reason ,for me, to admit
what seemed a very crazy feature .
No i can sleep happy ;)

Thank you all , and good night from Italy .

bye .

[Peter Maas]

Nicola Mingotti schrieb:

2) Like C -----> Char is converted to int
#include<stdio. h>
int main(){
printf("%i %i", '1' > 1 , '1' + 1 );
return 0;
}
That's not really a conversion. '1' is 0x31 in memory
and 0x31 > 1. C simply compares memory locations, so
comparisons are perhaps even be machine dependent.
Unlike C, Python's comparison results for different types
are defined in a strange but archicture independent way, see
Python Library Reference 2.3.3. The important thing is that
objects of different types are not equal.
Excuse me again for mistakes or possible (but unwanted)
rude language .

Sorry, no excuse. :-) Really, please stop excusing, for the
following reasons:

1. It's GREAT that you post in English, as I don't understand Italian.
2. Native speakers also make mistakes.
3. Nobody expects an excuse (I think).

:-)

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel [phone] Fax [phone] eMail pe********@mplu sr.de
-------------------------------------------------------------------