允许套房周围的支架 [英] allowing braces around suites
问题描述
通常在重新分解代码时，我需要更改
的缩进级别一些代码。由于缺少结束标记，我的Emacs必须在重新缩进时使用启发式方法，这有时会导致
错误。当然这真的是_my_错，不是Emacs''，但是它是b / b
烦恼所有相同的。
a同事使用#fi，＃yrt标记块的结尾，但是我不会发现这个令人满意，因为Python和Emacs都没有任何关于魔术评论意味着什么的知识。
我的建议是允许大括号标记套件。 Python仍然严格执行缩进，事实上，在某些方面它比以前更加严格
。使用大括号并错误地重新缩进的代码将会在编译期间导致语法错误。
代码可能如下所示：
< br $>
def appraise_insurance（rental_cars）：
{
断言isinstance（rental_cars，（list，tuple））
$在rent_cars的汽车b $ b：
{
如果car.make ==" Lamborghini"：
{
car.insurance = 1000.00
}
elif car.make ==" Lada"：
{
car.insurance = 50.00
}
else：
{
car.insurance = 100.00 < br $>
}
}
logger.debug（保险价值更新）
}
现在，我不建议写这样的代码，实际代码行之间有太多的空气.b $ b空气。我只会添加大括号，其中有
a风险重新缩进改变程序的含义，如下所示：
def appraise_insurance（rental_cars） ：
断言isinstance（rental_cars，（list，tuple））
for rent in rental_cars：
{
if car.make ==" Lamborghini"：
car.insurance = 1000.00
elif car.make ==" Lada"：
car.insurance = 50.00
否则：
car.insurance = 100.00
}
logger.debug（保险价值更新）
单对括号就足够了。现在没有Emacs
的风险，包括不被注意到的else分支的调试行。
实现这个的补丁很简单，仅限于
tokenizer。就像它的立场一样，它需要把括号放在上面的例子中，如果是真的那么你就不能写出
：{
代码
}否则{
代码
}
a单支撑式提高
软件项目的可读性和样式一致性。我的补丁确实允许两种风格：减少
行数，你可以把其他：放在与结束
大括号相同的行上。
如果为真：
{
代码
}否则：
{
代码
}
两种款式，大括号排队和恕我直言这使得它更容易
确定中等大小的块的开始和结束位置。
开口支撑后可能没有代码，但它是一个好地方
放一个评论，所以在实践中添加的行数可能不是那么
大。
a小警告：它打破代码看起来像这样：
def test_varargs1（self）：
""" some text"""
{} .has_key（0）
这个函数来自Lib / test / test_call.py，但是文件字符串
被添加以使我的修补Python拒绝它并出现语法错误。 />
问题在于支撑与上面一行相同的缩进级别
将始终标记新套件的开头。我不认为这样的代码很普遍，但有兴趣听到相反的
经验。对此问题的一个解决方法是让解析器告诉
tokenizer是否套件可能跟随当它要求下一个
令牌时，我还没有写下这样的补丁。
a补丁相对于Python 2.4a2可用于<
http ：//heim.ifi.uio.no/~kjetilho/hac...on-2.4a2.patch
您怎么看？我应该写一个PEP吗？
-
Kjetil T.
often when re-factoring code, I need to change the indent level of
some chunk of code. due to the lack of an end marker, my Emacs has to
use heuristics when re-indenting, and this will occasionally lead to
mistakes. of course this is really _my_ fault, not Emacs'', but it''s
annoying all the same.
a colleague uses #fi, #yrt etc. to mark the end of blocks, but I don''t
find this satisfactory since neither Python nor Emacs has any
knowledge of what the magic comment means.
my suggestion is to allow braces to mark the suites. Python is still
strictly enforcing indentation, in fact, in some ways it''s stricter
then before. code which uses braces and is wrongly re-indented will
always cause a syntax error during compilation.
code could look like this:
def appraise_insurance(rental_cars):
{
assert isinstance(rental_cars, (list, tuple))
for car in rental_cars:
{
if car.make == "Lamborghini":
{
car.insurance = 1000.00
}
elif car.make == "Lada":
{
car.insurance = 50.00
}
else:
{
car.insurance = 100.00
}
}
logger.debug("Insurance values updated")
}
now, I don''t suggest to write code like that, that has far too much
air between actual codelines. I''d only add the braces where there is
a risk re-indentation changing the meaning of the program, like this:
def appraise_insurance(rental_cars):
assert isinstance(rental_cars, (list, tuple))
for car in rental_cars:
{
if car.make == "Lamborghini":
car.insurance = 1000.00
elif car.make == "Lada":
car.insurance = 50.00
else:
car.insurance = 100.00
}
logger.debug("Insurance values updated")
the single pair of braces is enough. there is now no risk of Emacs
including the debug line into the else branch unnoticed.
the patch to implement this is very simple and restricted to the
tokenizer. as it stands, it requires the braces to be placed as in
the above examples, you _can''t_ write
if True: {
code
} else {
code
}
a single braces style improves readability and style consistency among
software projects. my patch does allow two styles, though: to reduce
line count you can put the else: on the same line as the closing
brace.
if True:
{
code
} else:
{
code
}
in both styles, the braces line up and IMHO this makes it easier to
identify where a medium sized block begins and ends.
there can be no code after an opening brace, but it''s a good place to
put a comment, so in practice the number of added lines may not be so
large.
a small caveat: it breaks code which looks like this:
def test_varargs1(self):
"""some text"""
{}.has_key(0)
this function is taken from Lib/test/test_call.py, but the doc string
was added to make my patched Python reject it with a syntax error.
the problem is that a brace at the same indent level as the line above
will always mark the beginning of a new suite. I don''t think such
code is widespread, but would be interested in hearing contrary
experiences. one fix for this issue is to have the parser tell the
tokenizer whether "a suite may follow" when it asks for the next
token, but I haven''t persued writing such a patch.
a patch relative to Python 2.4a2 is available at
http://heim.ifi.uio.no/~kjetilho/hac...on-2.4a2.patch
what do you think? should I write a PEP?
--
Kjetil T.
推荐答案
Kjetil Torgrim Homme写道：
...
Kjetil Torgrim Homme wrote:
...
您怎么看？我应该写一个PEP吗？
what do you think? should I write a PEP?
问python它的想法更有趣：
michaels @ pc474 ：〜/文件及GT; python
Python 2.3.3（＃1，2004年4月6日，01：47：39）
[GCC 3.3.3（SuSE Linux）] on linux2
输入help，copyright，credit等。或许可证或更多信息。
It''s more fun to ask python what it thinks:
michaels@pc474:~/Documents> python
Python 2.3.3 (#1, Apr 6 2004, 01:47:39)
[GCC 3.3.3 (SuSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
from __future__ import braces
File"< stdin>"，line 1
语法错误：没有机会
from __future__ import braces File "<stdin>", line 1
SyntaxError: not a chance
^^^^^^^^^^^^
我怀疑你可能很难在任何地方找到这个;）
问候，
迈克尔。
-
Mi ************ @ rd.bbc.co.uk
英国广播公司，研发部门
Kingswood Warren，Surrey KT20 6NP
此消息（及任何附件）可能包含个人观点
除非另有说明，否则不是BBC的观点。
^^^^^^^^^^^^
I suspect you might have a hard time getting anywhere with this ;)
Regards,
Michael.
--
Mi************@rd.bbc.co.uk
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP
This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.
[ Michael Sparks]：
[Michael Sparks]:
Kjetil Torgrim Homme写道：
Kjetil Torgrim Homme wrote:
>你怎么看？我应该写一个PEP吗？
> what do you think? should I write a PEP?
我怀疑你可能很难到达这个地方;）
I suspect you might have a hard time getting anywhere with this ;)
嗯，在之前的讨论中，我已经读到，支撑的支持者
希望它们作为严格缩进的替代方案。这不是
的情况，所以代码仍然是pythonic，IMO。
-
Kjetil T.
well, in the previous discussions I''ve read, the proponents of braces
want them as an alternative to strict indentation. that''s not the
case here, so the code is still kept pythonic, IMO.
--
Kjetil T.
2004年8月27日星期五12:40:02 +0100，Michael Sparks
< mi ****** @ rd.bbc.co.uk>写道：
On Fri, 27 Aug 2004 12:40:02 +0100, Michael Sparks
<mi******@rd.bbc.co.uk> wrote:
Kjetil Torgrim Homme写道：
...
Kjetil Torgrim Homme wrote:
...
您怎么看？我应该写一个PEP吗？
what do you think? should I write a PEP?
显式[*]块结束标记的整个主题提出来了
在1994年5月详细讨论过：
http://groups.google.com/groups?hl=e...8%40vicorp.com
（我正在查看clpy的旧档案，试图找到关于
三重引用字符串和文档字符串的来源的信息，两者都是
出生于1994年4月左右）
无论历史如何，在我看来你的问题可能是通过修改你的emacs来更好地解决你的问题模式考虑空白更多
正确 - AFAICT没有理由为什么它应该在你的例子中拿起
日志行并将其缩进到与
else：block。
The whole topic of explicit[*] end-of-block markers was brought up and
discussed at great length in May 1994:
http://groups.google.com/groups?hl=e...8%40vicorp.com
(I was looking at the old archives of c.l.py to try and find info on
the origins of triple-quoted strings and docstrings, both of which
were born around April 1994)
Regardless of history, it looks to me like your problem could be
better solved by modifying your emacs mode to consider whitespace more
correctly -- AFAICT there is no reason why it should ever pick up the
logging line in your example and indent it to the same level as the
else: block.
这篇关于允许套房周围的支架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
