有点奇怪的字典行为 [英] A bit weird dictionary behavior
问题描述
您好，
刚刚注意到这一点：
Python 2.5.1（r251：54863，2008年1月17日，19：35： 17）
[GCC 4.0.1（Apple Inc. build 5465）]在darwin上
输入help，copyright，credit等等。或许可证或欲获得更多信息。
>> {1：2}
{1：2}
>> {True：False}
{True：False}
>> {1：2，True：False}
{1：False}
这必须是因为
>> True == 1和{1：2}中的True
True
但它仍然感觉不对。是否值得提交错误？
干杯，
。佩克
9月22日，10：25，Pekka Laukkanen < p ... @ iki.fiwrote：
您好，
只是注意到了这一点：
Python 2.5.1（r251：54863，2008年1月17日，19：35：17）
[GCC 4.0.1（Apple Inc. build 5465）]在darwin上br />
输入help，copyright，credit等等。或许可证或更多信息。>> {1：2}
{1：2}
> {True：False}
{True：False}
> {1：2，True：False}
{1：False}
这必须是因为
> True == 1和{1：2}中的True
True
这正是原因！
但它仍然感觉不对。是否值得提交错误？
我不认为它可以被视为一个bug，因为你给了
以上因为字典键是由定义独特的
尊重平等。
也许你可以把它称为令人惊讶的功能。 :)
-
Arnaud
Pekka Laukkanen：
但它仍然感觉不对。是否值得提交错误？
感觉不对，因为它是。用更整洁的语言（Pascal，Java等）
布尔值和整数必须是不同的类型。保持布尔值和
整数分离也可以避免一些错误（我不知道多少/
经常）。
但Python语言从C复制许多东西，其中大多数东西都是为了实际目的和最高效率而选择的（并且来自
更简单的Python实现，其中没有布尔类型，
所以bool被嫁接了），所以它不是一个bug，我认为它不会很快被修复（Python 3可能是最后一次改变的机会）它，对于
未来几年）。
所以你可能不得不忍受这种不合逻辑的行为。
另一方面它有一些实用优势，你可以这样做：
总和（x == y代表x可迭代）
这也等于更多整洁：
总和（如果x == y，则x表示可迭代x）
关于dict，它们是动态类型的，但编程良好
练习（来自b的经验）那些咬你的人）
告诉你通常最好小心插入不同类型的字母到dict;通常情况下最好避免这样做。
再见，
bearophile
Tino Wildenhain：
不会是
len（[如果x == y则x可迭代x]）
甚至更短：
iterable.count（y）
无法正常工作并且阅读效果更好？
第一个版本创建一个实际列表只是为了占用它的长度，
想想它可以使用多少内存。
第二个版本要求''iterable''对象有一个count（）
方法，一般来说这是假的。
即使用布尔值计算也不是必要的
因为''和''和'foo如果bar blub''工作得更好
所以类型合并
bool - int - float真的可以消失。
我不明白。
再见，
熊宝宝
Hello,
just noticed this:
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>{1: 2}
{1: 2}
>>{True: False}
{True: False}
>>{1: 2, True: False}
{1: False}
This must be because
>>True == 1 and True in {1: 2}
True
but it still doesn''t feel exactly right. Would it be worth submitting a bug?
Cheers,
.peke
On 22 Sep, 10:25, "Pekka Laukkanen" <p...@iki.fiwrote:Hello,
just noticed this:
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.>>{1: 2}
{1: 2}>{True: False}
{True: False}
>{1: 2, True: False}
{1: False}
This must be because
>True == 1 and True in {1: 2}
TrueThat''s exactly the reason!
but it still doesn''t feel exactly right. Would it be worth submitting a bug?I don''t think it can be considered as a bug, for the reason you gave
above and because dictionary keys are by definition unique with
respect to equality.
Perhaps you could call it a "surprising feature" :)
--
Arnaud
Pekka Laukkanen:but it still doesn''t feel exactly right. Would it be worth submitting a bug?It feels wrong because it is. In a tidier language (Pascal, Java, etc)
a boolean and an integer must be different types. Keeping booleans and
integers separated may avoid some bugs too (I don''t know how many/
often).
But the Python language copies many things from C, where most things
are chosen for practical purposes and maximum efficiency (and from
much simpler Python implementations, where there was no boolean type,
so bools are grafted in), so it''s not a bug, and I think it will not
be fixed soon (Python 3 was probably the last chance to change it, for
several years to come).
So you probably have to live with this illogical behavior.
On the other hand it has some little practical advantages, you can do:
sum(x == y for x in iterable)
That also equals to a more tidy:
sum(1 for x in iterable if x == y)
Regarding the dict, they are dynamically typed, but good programming
practice (that comes from experience of bugs that have bitten you)
tells you that generally it''s better to be careful with the inserting
different types into a dict; often it''s better to avoid doing it.
Bye,
bearophile
Tino Wildenhain:
Wouldn''t
len([x for x in iterable if x==y])
or even shorter:
iterable.count(y)
not work and read better anyway?The first version creates an actual list just to take its length,
think about how much memory it may use.
The second version requires the ''iterable'' object to have a count()
method, and in general this is false.
even calculating with boolean values isn''t neccessary
since ''and'' and ''foo if bar else blub'' are working much better
so the type coalescing
bool - int - float can really go away.I don''t understand.
Bye,
bearophile
这篇关于有点奇怪的字典行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
