"也"平衡“其他” ？ [英] "also" to balance "else" ?
问题描述
最近似乎有大量关于流量控制的讨论
增强功能。 with，do and dowhile，case等...所以这里是我的
流量控制建议。 ;-)
它发生在我身上（几个星期前，我试图找到一个最好的方法来形成一个if-elif-else块，这是一个非常一般的等级，''也''
声明可能有用。所以我想知道其他人会怎么想。
。
'''''将与''else''的意思相反。而对于
for-else ...会纠正我认为不一致的内容。
目前for循环中的else块被执行，如果循环是
已经完成，这似乎是我的后退。我希望其他的
$ b如果循环被打破，$ b完成。如果''的条件为假，如果''else阻止执行，那么这似乎更加恒定。
''也会这样工作。
for x in< iteriable>：
BLOCK1
if< condition> ：休息#do else block
还：
BLOCK2
els e：
BLOCK3
如果循环完成则执行也是块（如当前的
else），以及如果没有，则执行else块。
而< condition1>：
BLOCK1
如果< condition2>：break ＃jump to else
还：
BLOCK2
else：
BLOCK3
这里如果while循环在while< condition1>结束时，BLOCK2
执行，或者如果执行了break，则执行BLOCK3。
In和如果声明......
如果< condition1>：
BLOCK1
elif< condition2>：
BLOCK2
elif< condition3>：
BLOCK3
还：
BLOCK4
else：
BLOCK5
这里，如果以前的条件为真，那么也会执行该块，
否则就会执行else块。
和''暂时''< g>，有可能''alif''，（也 - 如果），这样使用
。
如果< condition1>：
BLOCK1
alif< condition2>：
BLOCK2
休息＃跳过也阻止
alif< ; condition3>：
BLOCK3
alif< condition4>：
BLOCK4
还：＃在租约1条件是真的
BLOCK5
其他：＃没有条件评估为真
BLOCK6
哪里只有一个elif会评价为真，任何或所有''alif'都可以
评价为真。这类似于一些案例陈述，除了可以评估所有
alif条件。不是一个真实的案例陈述，但是一个好的
更换速度不是主要关注点吗？
我不确定是否''elif '和''alif'可以或应该一起使用吗？
可能需要优先规则。或简单的说，所有'和'
alif'必须先于任何elif'。那么也许alif'之间的elif'的
可能有用吗？例如，alif< condition2>可能和''elif''
相反，所以不需要上面的突破。
''也''可以在没有上面例子中的其他内容，当然还有
''else''不需要''也''。
我想这给了Pythons一般的流量控制一些不错的对称性和b $ b和一致的特征，这些特征对我来说非常有吸引力。任何人
同意吗？
任何理由这都是个坏主意？是否还有其他任何语言的
？ （我之前没见过。）
更改for-else可能是个问题...这可能是3.0愿望
列表因为这个项目。
与elif太相似了？
从好的方面来说，我认为这有助于伪代码<很好的是
的Python。
干杯，罗恩
< blockquote>我的第一个反应是这很糟糕，否则循环上的条款是足够令人困惑的。但是，如果我更多地考虑它，我正在升温到
的想法。另外/ Else for循环清晰，对称，并且很有用。
反转else的meanign将破坏代码，但它没有被使用
$ b经常是$ b，开始时这是一件令人困惑的事情，没有什么不对。
如果它打破了某些东西（慢慢地！）。
Alifs看起来很邪恶，我无法轻易推断出控制流程，但是
那么它们是一个新想法。我会对那个人保持开放的态度。
我认为最好的方法是将the / else语法与
相同的功能进行比较现在看起来像是在python中[暗示某人现在比我更多时间
的时间;）]。我会投票给两个更简洁，更可读的两个。
-Dan
Ron Adam写道：它发生在我身上（几个星期前，他试图寻找形成if-elif-else块的最佳方法，在非常一般的层面上，''也''
声明可能是有用的。所以我想知道其他人会怎么想它。
for x in< iteriable>：
BLOCK1
如果< condition> ;: break #do else block
还：
BLOCK2
否则：
BLOCK3
对于这个特定的情况，你可以重写
当前Python中的代码
for x in< iterable>：
BLOCK1
如果< condition>：
BLOCK3
break
else：
BLOCK2
为了使你的建议有用，你需要一个
的例子，如下所示当前的Python
for x in< iterable>：
...
if< condition>：
BLOCK3
休息
...
如果< condition>：
BLOCK3
休息
否则：
BLOCK2
也就是说，BLOCK3; break在循环中多次出现
。我的直觉是，这并不经常发生，足以需要一种新的语法来简化它。
你能指出一些现有的代码吗？改善
还带你的/其他？
而< condition1>：
BLOCK1
如果< condition2>：break＃jump to else
另外：
BLOCK2
否则：
BLOCK3
这里如果while循环结束于while< condition1> ;,那么BLOCK2
执行，或者如果执行了中断，BLOCK3执行。
与
相同（在当前的Python中）< condition>：
BLOCK1
if< condition2>：
BLOCK3
break
else：
BLOCK2
In和if声明......
如果< condition1>：
BLOCK1
elif< condition2>：
BLOCK2
elif < condition3>：
BLOCK3
还：
BLOCK4
否则：
BLOCK5
这里，如果有的话还会执行块条件为真，否则else块将执行。
那是......时髦。什么时候有用？
一个或许是hackish解决方案我已经为罕见的情况做了什么
我认为你的建议很有用
而1：
如果< condition1>：
BLOCK1
elif< condition2>：
BLOCK2
elif< condition3>：
BLOCK3
else：
＃couldn什么都不做
休息
BLOCK4
休息
我觉得这给了Pythons一般的流量控制一些不错对称的
和一贯的特征似乎对我很有吸引力。任何人都同意吗？
否。有更多的方法来控制流程并不能代表那些'
易于阅读。
在思考（或听到）关于新的Python
语言更改之后我通常的下一步是查看现有代码并查看是否如果这是一个常见或罕见的问题，现有的代码会更容易阅读/理解并获得
的想法。也许你可以指出
这几行的例子吗？
Andrew
da *** @ dalkescientific.com
Eloff写道：我的第一反应是这太可怕了，否则循环上的条款足够令人困惑。但是，如果我更多地考虑它，我正在热衷于这个想法。此外/其他循环是清晰，对称，并且将是有用的。
反转其他的手段将破坏代码，但它不经常使用
，它是一个令人困惑的事情开始时，没有什么不对，如果它开始时被打破了一些东西（慢慢地！）。
Alifs看起来很邪恶，我无法推断很容易控制流程，但是这是一个新想法。我会对那个保持开放的态度。
是的，这可能是因为它是新的。 Alifs将在你想要的地方使用
来测试多个可能的值，并且需要以不同的方式响应
，具体取决于值。它们可能不会像精灵那样频繁使用。
alifs是一种串联方式，如果'作为一个整体组合在一起。以下将
等同于if-alif-also-else。
didif = False
如果val == condition1 ：
didif = True
BLOCK1
如果val == condition2：
didif = True
BLOCK2
如果val == condition3：
didif = True
if didif：
BLOCK3
其他：
BLOCK4
if-alif-also-else版本不需要额外的名称来标记是否有任何
的条件是真的。
如果val == condition1：
BLOCK1
alif val = =条件2：
BLOCK2
alif val == condition3：
BLOCK3
还：
BLOCK4
否则：
BLOCK5
但我想我们需要找一些真实的用例''s使它成为
令人信服。
我认为最好的方法是将also / else语法与
相同的功能相比较现在是python [暗示现在比我更有时间的人;）]。我会投票支持两者中更简洁，更可读的内容。
-Dan
如果是if-also，等效代码需要一个额外的局部变量
和一个额外的if语句。
iftest = False
if < condition>：
iftest = True
BLOCK1
elif< condition>：
iftest = True
BLOCK2
if iftest：
BLOCK3
这是让我思考的模式有一个也。我当时正在解析和格式化doc字符串，并且还允许它成为
。
如果<条件>：
BLOCK1
elif< condition>：
BLOCK2
还：
BLOCK3
哪个更容易阅读。
Ron
There seems to be a fair amount of discussion concerning flow control
enhancements lately. with, do and dowhile, case, etc... So here''s my
flow control suggestion. ;-)
It occurred to me (a few weeks ago while trying to find the best way to
form a if-elif-else block, that on a very general level, an ''also''
statement might be useful. So I was wondering what others would think
of it.
''also'' would be the opposite of ''else'' in meaning. And in the case of a
for-else... would correct what I believe to be an inconsistency.
Currently the else block in a for loop gets executed if the loop is
completed, which seems backwards to me. I would expect the else to
complete if the loop was broken out of. That seems more constant with
if''s else block executing when if''s condition is false.
''also'' would work like this.
for x in <iteriable>:
BLOCK1
if <condition>: break # do else block
also:
BLOCK2
else:
BLOCK3
where the also block is executed if the loop completes (as the current
else does), and the else block is executed if it doesn''t.
while <condition1>:
BLOCK1
if <condition2>: break # jump to else
also:
BLOCK2
else:
BLOCK3
Here if the while loop ends at the while <condition1>, the BLOCK2
executes, or if the break is executed, BLOCK3 executes.
In and if statement...
if <condition1>:
BLOCK1
elif <condition2>:
BLOCK2
elif <condition3>:
BLOCK3
also:
BLOCK4
else:
BLOCK5
Here, the also block would execute if any previous condition is true,
else the else block would execute.
And ''tentatively''<g>, there is the possible ''alif'', (also-if), to be
used this way.
if <condition1>:
BLOCK1
alif <condition2>:
BLOCK2
break # skip to also block
alif <condition3>:
BLOCK3
alif <condition4>:
BLOCK4
also: # at lease one condition was true
BLOCK5
else: # no conditions evaluated as true
BLOCK6
Where only one elif will ever evaluate as true, any or all ''alif''s could
evaluate as true. This works similar to some case statements except all
alif conditions may be evaluated. Not a true case statement, but a good
replacement where speed isn''t the main concern?
I''m not sure if ''elif''s and ''alif''s could or should be used together?
Maybe a precedence rule would be needed. Or simple that all also''s and
alif''s must precede any elif''s. Then again maybe alif''s between elif''s
could be useful? For example the alif <condition2> could be and ''elif''
instead, so the break above would''t be needed.
''also'' can be used without the else in the above examples, and of course
the ''else'' doesn''t need an ''also''.
I think this gives Pythons general flow control some nice symmetrical
and consistent characteristics that seem very appealing to me. Anyone
agree?
Any reason why this would be a bad idea? Is there an equivalent to an
also in any other language? (I haven''t seen it before.)
Changing the for-else is probably a problem... This might be a 3.0 wish
list item because of that.
Is alif too simular to elif?
On the plus side, I think this contributes to the pseudocode character
of Python very well.
Cheers, Ron
My first reaction was that this is terrible, else clauses on loops are
confusing enough. But if I think about it more, I''m warming up to the
idea. Also/Else for loops is clear, symmetrical, and would be useful.
Reversing the meanign of else will break code, but it''s not used that
frequently, and it was a confusing thing to begin with, nothing wrong
in breaking something (slowly!) if it was ''broken'' to begin with.
Alifs look evil, I couldn''t deduce the control flow very easily, but
then they are a new idea. I''ll keep an open mind on that one.
I think the best thing would be to compare the also/else syntax to what
identical functionality looks like in python now [hint to someone with
more time than me right now ;)]. I''d vote for whichever is the more
concise and readable of the two.
-Dan
Ron Adam wrote:It occurred to me (a few weeks ago while trying to find the best way to
form a if-elif-else block, that on a very general level, an ''also''
statement might be useful. So I was wondering what others would think
of it. for x in <iteriable>:
BLOCK1
if <condition>: break # do else block
also:
BLOCK2
else:
BLOCK3
For this specific case you could rewrite the code in
current Python as
for x in <iterable>:
BLOCK1
if <condition>:
BLOCK3
break
else:
BLOCK2
In order for your proposal to be useful you would need an
example more like the following in current Python
for x in <iterable>:
...
if <condition>:
BLOCK3
break
...
if <condition>:
BLOCK3
break
else:
BLOCK2
That is, where "BLOCK3;break" occurs multiple times in
the loop. My intuition is that that doesn''t occur often
enough to need a new syntax to simplify it.
Can you point to some existing code that would be improved
with your also/else?
while <condition1>:
BLOCK1
if <condition2>: break # jump to else
also:
BLOCK2
else:
BLOCK3
Here if the while loop ends at the while <condition1>, the BLOCK2
executes, or if the break is executed, BLOCK3 executes.
which is the same (in current Python) as
while <condition>:
BLOCK1
if <condition2>:
BLOCK3
break
else:
BLOCK2
In and if statement...
if <condition1>:
BLOCK1
elif <condition2>:
BLOCK2
elif <condition3>:
BLOCK3
also:
BLOCK4
else:
BLOCK5
Here, the also block would execute if any previous condition is true,
else the else block would execute.
That is ... funky. When is it useful?
One perhaps hackish solution I''ve done for the rare cases when
I think your proposal is useful is
while 1:
if <condition1>:
BLOCK1
elif <condition2>:
BLOCK2
elif <condition3>:
BLOCK3
else:
# couldn''t do anything
break
BLOCK4
break
I think this gives Pythons general flow control some nice symmetrical
and consistent characteristics that seem very appealing to me. Anyone
agree?
No. Having more ways to do control flow doesn''t make for code that''s
easy to read.
My usual next step after thinking (or hearing) about a new Python
language change is to look at existing code and see if there''s
existing code which would be easier to read/understand and get an
idea if it''s a common or rare problem. Perhaps you could point
out a few examples along those lines?
Andrew
da***@dalkescientific.com
Eloff wrote:My first reaction was that this is terrible, else clauses on loops are
confusing enough. But if I think about it more, I''m warming up to the
idea. Also/Else for loops is clear, symmetrical, and would be useful.
Reversing the meanign of else will break code, but it''s not used that
frequently, and it was a confusing thing to begin with, nothing wrong
in breaking something (slowly!) if it was ''broken'' to begin with.
Alifs look evil, I couldn''t deduce the control flow very easily, but
then they are a new idea. I''ll keep an open mind on that one.
Yes, it''s probably because it''s new. Alifs would be used where you want
to test for multiple possible values, and need to respond differently
depending on the values. They probably wouldn''t be used as often as elifs.
alifs is a way to string if''s together as a group. The following would
be equivalent to if-alif-also-else.
didif = False
if val == condition1:
didif = True
BLOCK1
if val == condition2:
didif = True
BLOCK2
if val == condition3:
didif = True
if didif:
BLOCK3
else:
BLOCK4
The if-alif-also-else version doesn''t need the extra name to mark if any
of the conditions were true.
if val == condition1:
BLOCK1
alif val == condition2:
BLOCK2
alif val == condition3:
BLOCK3
also:
BLOCK4
else:
BLOCK5
But I think we will need to find some real use case''s to make it
convincing.
I think the best thing would be to compare the also/else syntax to what
identical functionality looks like in python now [hint to someone with
more time than me right now ;)]. I''d vote for whichever is the more
concise and readable of the two.
-Dan
In cases of if-also, the equivalent code needs an extra local variable
and an additional if statement.
iftest = False
if <condition>:
iftest = True
BLOCK1
elif <condition>:
iftest = True
BLOCK2
if iftest:
BLOCK3
This is the pattern that caused me to think of having an also. I was
parsing and formatting doc strings at the time, and also would allow it
to become.
if <condition>:
BLOCK1
elif <condition>:
BLOCK2
also:
BLOCK3
Which is much easier to read.
Ron
这篇关于"也"平衡“其他” ？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
