关于PEP315的想法 [英] Thoughts on PEP315
问题描述
PEP315（循环增强）建议语法如下......
do：
...
条件：
...
动机IMO很好，但我不喜欢这个解决方案。它是
复制C do循环的问题（尽管这实际上是与C do循环不同的
）。
想象一下，你可以在一段代码中看到以下内容...
陈述1
条件：
语句2
问题是这个 - 这是一个新的旧式while循环，从
这一点开始，还是它''while''是新式while循环的一部分？鉴于
截取的视图通常只有一屏代码，这可能很难清楚。 ''statements1''可以在之前的'do：''之后跟随，
但是它可以在之前的''if ...：''或''之后同时跟随...
：''或者其他什么。
这种情况下任何人都不知道新的''做：''部分
（或者根本没想到的话）最终可能会被b。和b。行混淆。
当使用C''do''循环时，这不是一个不寻常的情况，只是因为那个循环在实践中很少使用 - 人们不会
期待它，所以当人们看到...
语句
}
while（condition）;
倾向于假设分号是一个错误，或者
而while行是一个传统的while循环，没有身体（不常见）
$如果条件有副作用，则在C代码中使用b $ b。
还有其他问题。例如...
do：
...
而c1：
。 ..
而c2：
...
第二个''while''行是新的开头循环，还是第一个循环（第二个退出点）的延续？如果它是一个
延续，你真的可能需要使用''通行证''
准备第二次循环...
做：
...
而c1：
...
传递＃断言前一个循环结束
而c2：
...
我基本上认为这太容易出错。
当遇到发明新语言语法的问题时，IMO第一个要做的事情应该总是要做要查看现有的其他语言
解决方案。为什么重新发明轮子？在这里，我将自己限制为
替代循环结构，它提供比基本循环时更多的灵活性（所以我不排除帕斯卡重复-until，对于
实例，与
while循环略有不同但不灵活。）
首先，ANSI Basic提供一个广义的循环，它有点灵活 - 它允许前提条件和后置条件。
做[条件]
...
循环[直到条件]
这在某些情况下很有用，但它并没有解决PEP315
问题。
C for循环值得快速提及，因为它不仅仅是循环的
整数。语法为
for（< initialisation> ;;< precondition> ;;<''increment''>）
语句
因为< initialisation>和<增量>可以是任何合法的C
语句，循环非常灵活。例如，结合逗号
运算符，它允许''in-step''循环，例如这个数组
反转器...
for（i =<第一项索引>，j =<列表项索引> ;; i< j; i ++，j--）
{
temp = array [i];
array [i] = array [j];
array [j] = temp;
}
再一次，这并没有解决PEP315的问题。
在灵活的循环方面，Ada基本上是爸爸mimimalist
for ...
循环
...
结束循环;
但你可以在开始时添加''while''部分或''for'部分...
while条件循环
...
结束循环;
for i in 1..10 loop
...
结束循环;
for i in reverse 1..10 loop
...
结束循环;
另外，你可以使用''退出''行'（在任何情况下）
上面给出一个有条件的休息时间...
循环
...
条件退出时;
...
结束循环;
这最后一个表格最终解决了PEP315问题。但是Ada稍微走了一点
。假设你有嵌套循环，并且你想退出
而不仅仅是最里面的那个？在Ada中，你可以命名循环，
按名称指定你要退出的那个...
outerloopname：loop
innerloopname：loop
...
条件时退出innerloopname;
...
exit outerloopname当条件;
...
结束循环;
结束循环;
那么什么可能值得在Python中使用？我喜欢''退出
''行的想法，这基本上就是PEP315'''''''''''''''''$ $ $ $ $ $ $ $
我认为不同的语法应该使用。我建议在Ada循环中''退出''
实际上意味着现在在Python中'break''意味着什么，
除了条件。所以我建议以下作为
的可能性......
而True：
......
中断如果< condition> ：
...
这没有新的关键字，但应该既清晰又有效。
解析器应该在现有的break
关键字之后立即使用分号，因此对于Python
解析器应该立即区分。
A''continue if'也可以考虑。
这足以处理没有新关键字且没有
''这是一个新循环吗？''混乱。如果在Python中需要使用命名循环
，那么还有一个显而易见的地方可以将''break''和''if'之间的名称放在
之间'。
所有其他循环创意怎么样呢？
1.将前提条件与后置条件相结合（ANSI Basic）...
没问题 - 只需在循环结束时加上'break if'。它是
不是''直到''后置条件，但谁在乎。如果有的话，拥有
所有具有相同''sense''的循环条件更加一致。
而True：
...
如果< condition>
中断：循环后
语句
2.步进循环（C for loop）......
这只是一段时间循环的语法糖...
setup1
setup2
条件：
声明
increment1
increment2
我个人意见是否需要更方便的迭代整数，但这种东西应该通常按照上面的方式完成。
3.命名循环（Ada）......
不知道。它可能是一个没有目的的功能。在Ada是我的主要语言的两个半年里，我不记得
曾经使用过它。
4.开始循环关键字，不需要条件（基本，
Ada）......
这是匹配的PEP315''做''，但实际上并不是必需的
如果你使用'break if'作为退出点 - 你可以简单地使用
''而没错：''没有歧义地开始循环。
但我承认 - 通过各种语言的原因是
因为我是厌倦了被指责试图将Python改成*。我不认为有人可以合理地指责我试图将Python
同时改为Basic，C和Ada（也许我应该找到办法
让Prolog融入其中。虽然我有点担心我的首选想法是从一种特定的语言改编而来的。仍然，
传统上我被指责试图将Python改为C，C ++，
Java，Pascal，Haskell或最近的C＃，所以至少Ada会（如果我好b $ b记得正确）做出改变;-)
-
Steve Horne
史蒂夫·霍恩，史蒂夫·霍恩，史蒂夫·霍恩，史蒂夫·霍恩，史蒂夫·霍恩，史蒂夫·霍恩，史蒂夫·霍恩，史蒂夫·霍恩，史蒂夫·霍恩等人。 <
@
.co.uk>写在
消息新闻：oa ******************************** @ 4ax.com ...
PEP315（增强的while循环）建议语法如下......
做：
...
条件：
...
我已经剪掉了你剩下的冗长分析，因为我认为
这个问题要深刻得多，鉴于
Python的结构，基本上是不可解决的。
困难在于没有明确而明显的方式
将下属分组与主要分组区分开来。
考虑if语句：
如果有的话：
blah blah
elif something_else：
blither
else：
bletch
如果我们看一下这个，在不知道
if语句的语法的情况下，它看起来像三个主要陈述。
没有先验的方法知道，从词汇
结构该语言，elif和其他人不能自己发生，但必须在
特定声明之前。你需要附加层
的句法关系。
在Ruby中考虑相同的结构：
如果什么东西
等等等等。
elsif something_else
blither
else
bletch
结束
最重要的是结束
语句关闭if。 elsif和else
是if语句中的条款，即使你不知道
，也没有
错过这个事实的方式
if结构的确切语法。
如果我们现在回到循环建议，
它变得相当明显需要什么<完成：
完成：
do：
bibbity
bobbity
boo
条件＃注意缺少冒号！
这至少是明确的
是怎么回事。
顺便说一下，我不认为我们需要这个
特定的句法糖，无论
我们装扮它的语法。
John Roth
-
Steve Horne
史蒂夫在九点点fsnet dot co dot uk
PEP315 (Enhanced while loop) suggests a syntax as follows...
do:
...
while condition:
...
The motives are IMO good, but I don''t like this solution. It
replicates a problem with the C do loop (even though this is actually
different to the C do loop).
Imagine that you can see the following in a piece of code...
statements1
while condition :
statements2
The question is this - is this a new old-style while loop starting at
this point, or is it the ''while'' part of a new-style while loop? Given
the truncated view typical of a single screenful of code, this could
be far from clear. ''statements1'' could follow after an earlier ''do:'',
but it could equally follow after an earlier ''if ... :'' or ''while ...
:'' or whatever.
This is a situation where anyone who is unaware of the new ''do:'' part
(or who simply didn''t think about it) could end up being confused by
the ''while ... :'' line.
This is not an unusual situation when the C ''do'' loop is used, simply
because that loop is quite rarely used in practice - people don''t
expect it, so when people see...
statements
}
while (condition);
the tendency is to assume that either the semicolon is a mistake, or
the while line is a conventional while loop with no body (not unusual
in C code if the condition has side-effects).
There are other issues. For example...
do :
...
while c1 :
...
while c2 :
...
Is the second ''while'' line the start of a new loop, or is it a
continuation of the first loop (a second exit point)? If it is a
continuation, do you really potentially need to use a ''pass'' to
prepare for a second loop...
do :
...
while c1 :
...
pass # to assert that the previous loop is ended
while c2 :
...
I basically think that this is too error-prone.
When faced with a problem inventing new language syntax, IMO the first
thing to do should always be to review other languages for existing
solutions. Why re-invent the wheel? Here, I''ll limit myself to
alternate-to-while-loop structures which provide more flexibility than
a basic while loop (so I''m excluding Pascals repeat-until, for
instance, which is slightly different to but no more flexible than the
while loop).
First, ANSI Basic provides a generalised loop which is a bit more
flexible - it allows both a precondition and a postcondition.
do [while condition]
...
loop [until condition]
This can be useful in some situations, but it doesn''t solve the PEP315
issue.
The C for loop deserves a quick mention because it isn''t just an
integer for loop. The syntax is
for (<initialisation>; <precondition>; <''increment''>)
statement
Because the <initialisation> and <increment> can be any legal C
statements, the loop is quite flexible. Combined with the comma
operator, for instance, it allows ''in-step'' loops such as this array
reverser...
for (i = <first item index>, j = <list item index>; i < j; i++, j--)
{
temp = array [i];
array [i] = array [j];
array [j] = temp;
}
Once again, though, this doesn''t solve the PEP315 problem.
In terms of flexible loops, Ada is basically the Daddy. The mimimalist
for is...
loop
...
end loop;
But you can add a ''while'' part or a ''for'' part to the start...
while condition loop
...
end loop;
for i in 1..10 loop
...
end loop;
for i in reverse 1..10 loop
...
end loop;
And in addition, you can use an ''exit when'' line (in any of the cases
above) to give essentially a conditional break...
loop
...
exit when condition;
...
end loop;
This last form finally handles the PEP315 problem. But Ada goes a
little further. Suppose you have nested loops, and you want to exit
more than just the innermost one? In Ada, you can name the loops and
specify by name which one you want to exit...
outerloopname: loop
innerloopname: loop
...
exit innerloopname when condition;
...
exit outerloopname when condition;
...
end loop;
end loop;
So what might be worth using in Python? I like the idea of an ''exit
when'' line, which is basically what the PEP315 ''while'' line gives, but
I think a different syntax should be used. I would suggest that ''exit''
in the Ada loop means essentially what ''break'' means in Python now,
except for the condition. So I would suggest the following as a
possibility...
while True :
...
break if <condition> :
...
This has no new keywords, but should be both clear and effective. The
parser should expect a semicolon immediately after existing break
keywords, so the distinction should be immediately clear to the Python
parser.
A ''continue if'' might be considered as well.
That is sufficient to handle PEP315 with no new keywords and without
the ''is this a new loop?'' confusion. Should the need for named loops
ever be considered in Python, there is also an obvious place to put
the name between the ''break'' and ''if''.
What about all those other loop ideas, though...
1. Combining a precondition with a postcondition (ANSI Basic)...
No problem - just put the ''break if'' at the end of the loop. It''s
not an ''until'' postcondition, but who cares. If anything, having
all loop conditions with the same ''sense'' is more consistent.
while True :
...
break if <condition> :
statements after loop
2. In-step looping (C for loop)...
This is just syntactic sugar for a while loop anyway...
setup1
setup2
while condition :
statement
increment1
increment2
My personal opinion is that there is some need for a more
convenient iterate-over-integers, but this kind of stuff should
normally be done as above.
3. Named loops (Ada)...
Don''t know. It may be a feature without a purpose. In the two
and a half years when Ada was my main language, I don''t remember
ever using it.
4. Start-of-loop keyword which doesn''t require a condition (Basic,
Ada)...
This is matched by the PEP315 ''do'', but is not actually necessary
if you use ''break if'' for the exit point - you can simply use
''while True :'' to start the loop without ambiguity.
But I admit it - the reason for going through the various languages is
because I''m sick of being accused of trying to change Python into *. I
don''t think anyone can reasonably accuse me of trying to change Python
into Basic, C and Ada at the same time (maybe I should find a way to
get Prolog into the mix). Though it is slightly worrying that my
preferred idea was adapted from one particular language. Still,
traditionally I''m accused of trying to change Python into C, C++,
Java, Pascal, Haskell or more recently C# so at least Ada will (if I
remember right) make a change ;-)
--
Steve Horne
steve at ninereeds dot fsnet dot co dot uk
"Stephen Horne" <
@
.co.uk> wrote in
message news:oa********************************@4ax.com...
PEP315 (Enhanced while loop) suggests a syntax as follows...
do:
...
while condition:
...
I''ve snipped the rest of your lengthy analysis because I think
the problem is much deeper, and is essentially insoluble given
the structure of Python.
The difficulty is that there is no clear and obvious way of
distinguishing subordinate groupings from the main grouping.
Consider the if statement:
if something:
blah blah
elif something_else:
blither
else:
bletch
If we look at this, without knowing the syntax of the
if statement, it looks like three primary statements.
There is no a priori way of knowing, from the lexical
structure of the language, that elif and else cannot
occur by themselves, but must be preceeded by
a specific statement. You need the additional layer
of the syntactic relationships.
Consider the same structure in Ruby:
if something
blah blah
elsif something_else
blither
else
bletch
end
The thing that makes all the difference is the "end"
statement which closes the if. The elsif and the else
are clauses within the if statement, and there is no
way of missing that fact even if you don''t know the
exact syntax of the if structure.
If we now go back to the loop suggestion,
it becomes rather obvious what needs to be
done:
do:
bibbity
bobbity
boo
while condition # note the lack of a colon!
This is at least unambiguous as to what is
going on.
I don''t, by the way, think that we need this
particular piece of syntactic sugar, regardless
of the syntax we dress it up in.
John Roth
--
Steve Horne
steve at ninereeds dot fsnet dot co dot uk
这篇关于关于PEP315的想法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
