'1'+ 1 ==>真的??? [英] '1' + 1 ==> True ???

问题描述

我获得了这个结果：

------

''1''> 1
True

------

python2.2.3和2.3.3。

（是的，在python中） 2.2我得到1而不是真的）


但是

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

-------


和

----------------- ------------''1''.__ gt __.__ doc __

''x .__ gt __（y）< ; ==> x> y''

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


所以我很困惑:)


这是一个错误还是有一个很好的理由

这种奇怪的行为？


谢谢大家。


再见。


（请原谅英语错误）

解决方案

2004年3月18日星期四03:45:56 +0100，Nicola Mingotti写道：

我得到了这个结果：
------

''1''> 1正确
------
使用python2.2.3和2.3.3。
（是的，在python 2.2中我得到1而不是True）


这应该不足为奇;值是不同的，所以一个将是

大于另一个;但是比较它们没什么用。

但是
------''1''+ 1 TypeError
-------


这也不应该令人惊讶。添加一个字符和一个数字

没有明确正确的含义。

和
----------------- ------------''1''.__ gt __.__ doc __

''x .__ gt __（y）< ==> x> y''
-----------------------------

显示比较几乎是你所期望的。再说一遍，

虽然比较不同类型的结果，如字符和

整数并不是特别有用。

所以我是有点疑惑:)

这是一个错误还是有这个奇怪行为的一个很好的理由

你期待什么行为？不知道很难

解释为什么现实不同。


-

\"法官：一名标记自己论文的法学院学生。 - Henry L. |

` \ Mencken |

_o__）|

Ben Finney< http://bignose.squidly。 org />

Nicola Mingotti写道：

我得到了这个结果：
------

''1''> 1正确
------
使用python2.2.3和2.3.3。
（是的，在python 2.2中我得到1而不是True）


是的，除了复数之外，对不同类型的
对象进行比较是有效的。对于特定实现，订单保证是一致的（例如，这里的字符串是/ b $ b被认为大于整数）。但是你不能保证行为

从实现到实现都是一样的（也就是说，它是完全有效的另一个实现考虑ints小于

字符串）。

但是
------''1''+ 1 TypeError
-------


这是正确的，添加字符串和整数是一种类型错误，因为它在Python中没有任何意义。 Python是强类型的，因此它不清楚这个操作意味着什么。你的意思是int（''1'）+ 1或''1''

+ str（1）？

和
---- -------------------------''1''.__ gt __.__ doc __

''x .__ gt __（y）< == > x> y''
-----------------------------

我不明白这个片段对前两个有什么影响。

所以我有点困惑:)

这是一个bug还是这个奇怪的行为是否有一个很好的理由？

在像Python这样强大，动态类型的语言中，它对

关系运算符通常在不同类型的对象之间工作，即使结果不是立即有用，因为你经常

我不知道你有一个对象的类型，所以不能保证

你总是将苹果与苹果进行比较。


还有其他方法，比如限制标准关系运算符只需使用相同类型的对象并提高

TypeErrors，并引入一组新的关系运算符

这是对原谅的对于不同类型的不兼容的物品（这是我用我的项目做的事情，其中​​`eq''

需要类型兼容性（并且如果不是满意）但

`seq''（安全相等）只返回false而不是引发错误

与不兼容的类型。但是，这不是Python历史上使用的方法。


另外，因为类型决定了操作的行为在

强类型语言，如Python，而不是操作，它对于具有多种含义的

操作很有用（+可以表示算术加法

但也是字符串连接） - 可以使用强类型语言

- 拒绝含糊不清的论据，而不是试图猜测它是什么

你的意思。


-

__ Erik Max Francis&& ma*@alcyone.com && http://www.alcyone.com/max/

/ \美国加利福尼亚州圣何塞市&& 37 20 N 121 53 W&& & tSftDotIotE

\ __ /真正的光/爱是否闪现

- Sandra St. Victor

2004年3月18日星期四13:24:14 +1050，Ben Finney写道：

2004年3月18日星期四03:45:56 +0100，Nicola Mingotti写道：

我得到了这个结果：
------

> ''1''> 1正确
------
这不应该是令人惊讶的;值是不同的，所以一个将是大于的。另一个;但比较它们并没有多大用处。


这里我期待Undefined Operation或者，如果这是定义的，

这意味着''1'和1是可比较的，因此，1是

被视为字符串或''1'是被视为一个数字。但是....


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

> ''1''+ 1

TypeError
-------


有了这个结果，我发现以前都没有提到的可能性

是可能的，因为在第一种情况下我会期望，结果，''11'和

，在第二种情况下，我会期待一个数字。我得到TypeError所以，我认为

这是不合逻辑的。


这也不应该令人惊讶。添加字符和数字
没有明确正确的含义。
另外比较一个字符串和一个字符有没有unambiguos含义，

有吗？


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

>''1''.__ gt __.__ doc __

''x .__ gt __（y）< ==> x> y''
-----------------------------

显示比较结果几乎是你所期待的。再说一遍，
虽然比较不同类型如字符和
整数的结果并不是特别有用。

这里我希望字符串之间的''>''的定义。

和''chars''和''整数'之间''>''的定义给出了

返回了一个奇怪的结果。

我知道python正在增长并且是免费的所以我不希望所有内容都记录在案或者一切都是正确的，那就是我在这里问的原因。

你期待什么行为？在不知道为什么现实不同的情况下很难解释。

i想象两种可能性：


1）像CommmonLisp（clisp实现）----->一个严格的类型错误

[1]> （>" 1" 1）

*** - >：" 1"不是真的

2）像C -----> Char转换为int

#include< stdio.h>

int main（）{

printf（"％i％i" ，''1''> 1，''1''+ 1）;

返回0;

}

==> ; 1 50 $

再见。


再次打扰我，因为错误或可能（但不需要）

粗鲁的语言。

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)

解决方案

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

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

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 .

这篇关于'1'+ 1 ==&gt;真的???的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！