blocks|key|542669|text|你误解了这段代码的工作原理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|542670|您的字典只有两个键：True和False。True键可能有多个相互冲突的值，但在字典初始化时就会解决。|offset|length|style|CODE|542671|字典查找没有迭代。|542672|entityMap^0|0|A|4|F|5|L|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|K|$]]

You misunderstood how this code works.

Your dictionary has only two keys: <code>True</code> and <code>False</code>. There could be multiple conflicting values for the <code>True</code> key but that gets resolved at the initialization of the dictionary.

There's no iteration for a dictionary lookup.

blocks|key|544478|text|散列随机化不会影响您的应用程序。它应该只影响依赖字典中键的迭代顺序的应用程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|544479|尽管如此，我发现您的技术比简单的if..elif链更晦涩，效率也更低(构建一个新的dict并不便宜)。|offset|length|style|CODE|544480|entityMap^0|0|G|8|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Hash randomization will not affect your application. It should only affect applications that rely on the iteration order of keys in the dictionary.

That said, I find your technique both more obscure than the simple <code>if..elif</code> chain and also less efficient (building a new dict is not cheap).

blocks|key|1103379|text|使用字典散列条件的方式不会受到排序的影响。您严格使用键来访问字典，排序对您来说并不重要，因为您没有对键/值进行迭代。因此，您对字典的特定用法不受Python字典散列随机化的影响。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1103380|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The way you are using the dictionary to hash the condition would not be affected by the ordering. You are strictly using keys to access the dictionary and the ordering is not important to you as you are not iterating over the keys/values. So your particular usage of dictionary is immune to Python's dictionary hash randomization.

blocks|key|1103530|text|这很可能仍然有效，前提是词典是从左到右顺序构建的。关于无序迭代的点是字典构建后的遍历，而不是构造过程本身，而且在任何情况下，您都是对其进行索引，而不是对其进行迭代。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1103531|但坦率地说，依靠这种行为并不是个好主意。它是脆弱的，因为它依赖于假定的行为(虽然在规范中有一些东西可以保证这一点)，而且非常令人困惑，这在很大程度上是因为案例评估的顺序实际上是从右到左(即最正确的案例获胜)。一个更容易理解的解决办法如下：|1103532|return+(+a+if+a+>+0++else
+++++++++0+if+a+==+0+else
++++++++-a)|code-block|syntax|javascript|1103533|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

This will probably still work, on the assumption that the dictionary is built in left-to-right order. The points about unordered iteration are about traversal once the dictionary is built, not the construction process itself, and in any event, you are indexing into it, not iterating over it.

But frankly it's not a good idea to rely on this behaviour. It's fragile, as it relies on assumed behaviour (though perhaps there's something in the spec that guarantees this) and is highly confusing, in no small part because the order of evaluation of cases is effectively right-to-left (i.e., the right-most true case wins). A much more comprehensible solution is as follows:

<pre><code>return ( a if a &gt; 0 else
 0 if a == 0 else
 -a)
</code></pre>

blocks|key|1103581|text|首先，要意识到您的代码或多或少相当于：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1103582|def+f(a):
++++d+=+{}
++++d[True]+=+-a
++++d[a==0]+=+0
++++d[a>0]+=+a
++++return+d[True]|code-block|syntax|javascript|1103583|考虑到这一点，你的问题的答案就变得显而易见了。|1103584|为什么要费心使用这种晦涩的语法而不是简单的语法呢？即使是这个，也更容易读懂：|1103585|def+f(a):
++++return+a+if+a+>+0+else+0+if+a+==+0+else+-a|1103586|您似乎误解了您的代码真正在做什么这一事实应该是一个明确的迹象，表明您正在做错误的事情。|1103587|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|U|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

First, realize that your code is more or less equivalent to:

<pre><code>def f(a):
 d = {}
 d[True] = -a
 d[a==0] = 0
 d[a&gt;0] = a
 return d[True]
</code></pre>

With that in mind, answer to your question becomes obvious.

Why do you bother with this obscure syntax instead of something simpler?
Even this one is more readable:

<pre><code>def f(a):
 return a if a &gt; 0 else 0 if a == 0 else -a
</code></pre>

The fact that you seem to misunderstand what your code is really doing should be a clear sign that you're doing something wrong.

blocks|key|1103482|text|这是一段非常脏的代码，带字典的代码行需要几分钟才能阅读(尽管我使用Python已经3年了)，这将是很难调试的。下一个开发人员(阅读:半年后自己)将无法阅读这篇文章。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1103483|如果需要的话，可以用一个回调块替换交换机结构：|1103484|+{value1:+one_func,+value2:+another_func,+value3:+third_func}|code-block|syntax|javascript|1103485|如果只需要真/假，则不需要任何结构：|1103486|return+one_func()+if+check+else+another_func()|1103487|在很多情况下，开关可以被一系列的if+.返回：|1103488|if+check:
++++return+one_func()

return+another_func()+if+another_check+else+third_func()|1103489|所有这些都更加可读性和可调试性。|1103490|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|10|8|@]|9|@]|A|$G|H]]|$1|Q|3|R|5|6|7|11|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

This is a very dirty code, the line with the dictionary takes minutes to read (although I work with Python for 3 years), and this will be very hard to debug. The next developer (read: yourself in half a year) will not be able to read this.

switch construct can be replaced with a dict of callbacks, if you need them:

<pre><code> {value1: one_func, value2: another_func, value3: third_func}
</code></pre>

If you need only True/False, you don't need any structure:

<pre><code>return one_func() if check else another_func()
</code></pre>

In many cases, switch can be replaced with a chain of if ... return:

<pre><code>if check:
 return one_func()

return another_func() if another_check else third_func()
</code></pre>

All these are much more readable and debuggable.

blocks|key|624781|text|在示例中没有使用迭代，所以代码是安全的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|624782|但是，您的解决方案有点奇怪，boolean作为密钥的可读性不是很强。|offset|length|style|CODE|624783|你为什么不试试：|624784|switch+=+{
+++choice1:+func1
+++choice1:+func2
+++...
}|code-block|syntax|javascript|624785|以及：|624786|switch[variable]()|624787|entityMap^0|0|E|7|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@$D|W|E|X|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|Z|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|11|8|@]|9|@]|A|$M|N]]|$1|S|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|T|$]]

You are not using iteration in your example, so your code is safe. 

However, your solution is a little strange, <code>boolean</code> as a key is not very readable.

Why don't you try:

<pre><code>switch = {
 choice1: func1
 choice1: func2
 ...
}
</code></pre>

and:

<pre><code>switch[variable]()
</code></pre>

blocks|key|542737|text|只有当你做以下事情时，你才会受到影响：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|542738|+mydict.values()[0]|code-block|syntax|javascript|542739|依靠这个永远是相同的价值。你引用的医生说，这不一定会发生。|542740|但是，您的代码有一个需要考虑的问题，这与短路有关。如果你这样做了：|542741|if+a+==+0:
+++++return+0
elif+a+>+0:
+++++return+a
else:
+++++return+-a|542742|或者，更简洁(但可以说不那么容易理解)+return+0+if+a+==+0+else+a+if+a+>+0+else+-a，a是0，那么a+>+0永远不会被计算(即使你不在它上面的return也不会)。你的字典每一次都需要评估你给它的每一个键作为一个条件。尝试字典分派而不是链式if的唯一原因是效率，但在键不是常量且整个dict可预计算的情况下，您可能会损失惨重。|offset|length|style|CODE|542743|entityMap^0|0|0|0|0|0|K|16|1X|5|2J|6|3W|2|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|Y|8|@]|9|@]|A|$E|F]]|$1|M|3|N|5|6|7|Z|8|@$O|10|P|11|Q|R]|$O|12|P|13|Q|R]|$O|14|P|15|Q|R]|$O|16|P|17|Q|R]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|T|$]]

That will only affect you if you're doing things like:

<pre><code> mydict.values()[0]
</code></pre>

And relying on this to always be the same value. The docs you quote say that that isn't guaranteed to happen.

However, your code has one issue that you need to consider, and that is related to short-circuiting. If you do:

<pre><code>if a == 0:
 return 0
elif a &gt; 0:
 return a
else:
 return -a
</code></pre>

Or, more succinctly (but arguably less readably) <code>return 0 if a == 0 else a if a &gt; 0 else -a</code> , and a is 0, then <code>a &gt; 0</code> is never evaluated (and still won't be even if you don't <code>return</code> above it). Your dictionary needs to evaluate every key you give it as a condition every time. The only reason to try dictionary dispatch instead of chained <code>if</code>s is efficiency, but in the case where the keys aren't constant and the entire dict precomputable, you can lose out badly.

I like using dictionaries as a form of <code>switch</code> statment, by settings booleans as keys. Example:

<pre><code>&gt;&gt;&gt; def f(a):
... return {True: -a, a==0: 0, a &gt; 0: a}[True]
... 
&gt;&gt;&gt; f(-3)
3
&gt;&gt;&gt; f(3)
3
&gt;&gt;&gt; f(0)
0
</code></pre>

The key <code>True</code> works as an <code>else</code>/<code>default</code> case and is only returned if no other key is evaluated to <code>True</code>. I am guessing this assumes some sort of order of evaluation for iterating the dictionary. 

Now look at the following extract from the latest <a href="http://mail.python.org/pipermail/python-list/2012-April/1290792.html" rel="nofollow">release announcement from the Python team</a> for the newest versions of branches 2.6, 2.7, 3.1 and 3.2:

<blockquote>
 Hash randomization causes the iteration order of dicts and sets to be
 unpredictable and differ across Python runs. Python has never
 guaranteed iteration order of keys in a dict or set, and applications
 are advised to never rely on it. Historically, dict iteration order
 has not changed very often across releases and has always remained
 consistent between successive executions of Python. Thus, some
 existing applications may be relying on dict or set ordering.
</blockquote>

Does this mean that using dicts as switch calls will not be possible anymore? Or maybe I should use any other class (like <code>OrderedDict</code> or something)? Or maybe I'm completely off and it should not affect this at all?

Using dictionaries as switch statements in Python 2.7.3

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我喜欢使用字典作为switch状态的一种形式，通过设置布尔作为键。示例：>>> def f(a):...      return {True: -a, a==0: 0, a > 0: a}[True]... >>> f(-3)3>>> f(3)3>>> f(0)0键True作为else/default的情况工作，只有在没有其他键被计算到True时才返回。我猜这假设了某种迭代字典的计算顺序。现在查看

问在Python2.7.3中使用字典作为开关语句
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Python2.7.3中使用字典作为开关语句EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Python2.7.3中使用字典作为开关语句
EN