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

Ben Finney bignose-hates-spam at and-benfinney-does-too.id.au
Thu Mar 18 00:06:36 EST 2004


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/>



More information about the Python-list mailing list