Python的Symbols

Wednesday, July 26, 2006

Symbols in Python

 

Jeff Shell继我的DSL那个话题接续道：

有一些关于那方面的就像…很好.：all。在我的编辑器中，与字符串相比Symbols被着以不同颜色以示区分，使它们更加显眼。find :all，而非 findAll()、find(all=True)或find('all')的其中之一，可能会在Python里出现（除了man.. 这些Symbols，所有这些都没问题）

很显然，他并未通过Cheese Shop理解好我的SymbolType包的实用之处。;-)

不管怎样，Python无需改变语言就能很轻松地处理symbols。这就是我为什么强调函数程序（function application）和语法块（block syntax）的原因，其亦是Ruby与DSL’s有关的重要特性。到目前为止，在这二者之中语法块是最重要的。

有意思的是，Python实际上就快要获得PEP 340（Guido本人写的！）中的一个DSL-usable块的能力了。然而在最后时刻，其因过于灵活被拒之门外了。更明确的是，一篇有关用C实现的控制流macros问题的文章其中包含了一个是运行时执行语义的语句，Guido对此深信不疑。（最初的PEP340“块”语句本该允许块的实体（block body）在重新绑定“as”子句中的变量时一次不执行或执行多次）

实际上，对于很多DSL’s，PEP340即便已被选中也仍有许多不足之处。你真正需要的一个块主要是一些可以在它封装区域内共享变量并可能将这些变量进行绑定的函数定义。

总之，对于Python DSLs最好的解决方法大概应是创建一个macro或者语言扩展工具包，它可以实现syntax-sugared翻译成纯Python，其保留debug-info（比如，正确的行号可以使你在sugared代码中进行步进）。在这个方向上我已在（未发布的）SCALE库和BytecodeAssembler中逐步进行采纳，但距离我考虑利用它们作出更多事情来还将需要一段时间。

SCALE的目的只是使Python的词汇语法和缩排可以用于实现多种特定领域语言或者Python的扩展变量。（尽管目前只有唯一一个解析/反解析库的实现）而且，如果再加上适当的导入机制，它将可以使Python以仿Logix式进行无限扩展，而无需语法上的折衷、。（在语法或语义上Logix的基语言正好不是Python，我希望任何Python的扩展语言将从它们的根上成为纯粹的Python。）

幸运的是，Python为我们留足了扩展语言的空间。现在若不写解析代码它会不怎么实用。但也许在将来某一天这会发生改变。

 

（原文链接网址：http://dirtsimple.org/2006/07/symbols-in-python.html）