使用@扩展Python语法 [英] Extending Python Syntax with @
问题描述
似乎我们需要一种简单的方法来扩展Python语法，这不会破坏现有语法或与Python中的任何其他语法冲突，是很容易的类型，易于阅读，明显不同于基础
语法。似乎我们可以在这些
情况下很好地使用@符号。示例：
print @（separator = None）x，y，z
@ x，y：x * x + y * y - 匿名函数
@f（x，y） - 可以接受新参数的生成器函数
每次调用
@x @y @z - 方法定义中实例变量的缩写
这些例子中的每一个都是值得商榷的，但我的观点是
这样的许多增强请求，有些可能值得包含在核心语言中的
。如果有一个
一致的方式来添加这样的东西会很好。它肯定比添加丑陋的
语句更像''lambda''。
甚至可以允许有限的语言扩展
由用户提供，只要特殊的
符号引入了扩展名。这将允许Ruby或Lisp的灵活性，而不需要将语言分成许多方言的成本。
也许我们应该收集一些小的增强功能，如以上，
并将它们全部放入一个PEP中。有什么建议？宠儿小便？东西
你想看到，但不值得PEP本身？
- 戴夫
Seems like we need a simple way to extend Python syntax that doesn''t
break existing syntax or clash with any other syntax in Python, is
easy to type, easy to read, and is clearly distinct from the "base"
syntax. Seems like we could put the @ symbol to good use in these
situations. Examples:
print @(separator = None) x, y, z
@x,y:x*x+y*y -- anonymous function
@f(x,y) -- generator function that can accept new arguments
with each call
@x @y @z -- short for instance variables in a method definition
Each of these examples is debatable, but my point is that there are
many enhancement requests like this, and some may be worthy of
inclusion in the core language. It would be nice if there was a
consistent way to add stuff like this. It certainly beats adding ugly
statements like ''lambda''.
It might even be possible to allow limited extension of the language
by users, provided the extensions are introduced by the special
symbol. This would allow the flexibility of Ruby or Lisp without the
cost of forking the language into many dialects.
Maybe we should collect a bunch of little enhancements like the above,
and put them all into one PEP. Any suggestions? Pet peeves? Stuff
you would like to see, but not worthy of a PEP by itself?
-- Dave
推荐答案
David MacQuigg< dm*@gain.com> pisze：
David MacQuigg <dm*@gain.com> pisze:
似乎我们需要一种简单的方法来扩展Python语法，它不会破坏现有语法或与Python中的任何其他语法冲突，是
易于打字，易于阅读，并且明显不同于基础语法。
Seems like we need a simple way to extend Python syntax that doesn''t
break existing syntax or clash with any other syntax in Python, is
easy to type, easy to read, and is clearly distinct from the "base"
syntax.
不，我们不是。你需要它。
-
Jarek Zgoda
http://jpa.berlios.de/
David MacQuigg写道：
David MacQuigg wrote:
语法。似乎我们可以在这些情况下充分利用@符号。示例：
syntax. Seems like we could put the @ symbol to good use in these
situations. Examples:
不，不要那样做！我讨厌perl precisley，因为乱丢代码
带有''特殊字符''！蟒蛇代码的美妙之处在于，它就像一本书，用标点符号来帮助读者，而不是排版机的价值。
No, don''t do that!! I hate perl precisley because of littering the code
with ''special characters''! The beauty of python code as it is, is that
it reads like a book, with punctuation to help the reader, rather than
the typesetter.
" David MacQuigg" < dm*@gain.com>在消息中写道
news：s2 ******************************** @ 4ax.com ...
"David MacQuigg" <dm*@gain.com> wrote in message
news:s2********************************@4ax.com...
好像我们需要一种简单的方法来扩展Python语法，它不会破坏现有语法或与Python中的任何其他语法冲突，很容易类型，易于阅读，并且明显不同于基础语法。似乎我们可以在这些情况下充分利用@符号。示例：
Seems like we need a simple way to extend Python syntax that doesn''t
break existing syntax or clash with any other syntax in Python, is
easy to type, easy to read, and is clearly distinct from the "base"
syntax. Seems like we could put the @ symbol to good use in these
situations. Examples:
添加新关键字和运算符确实需要付费;
现有程序可能会中断。设计一种不会发生这种情况的语言很有可能
，但是Python不是那种语言。
事实证明，有一个非常简单的关键语言
带有关键字，其中添加新的不会破坏现有的
程序：将它们放入一个词法上可区分的命名空间。
碰巧使用的解决方案非常不愉快 -
，除非语法识别编辑器/ IDE支持它。有一天
人们可以通过任何旧的文本编辑器来编写
程序来解决他们的附件。能够在没有需要特殊格式化程序的情况下打印他们的程序，但那天不是今天，
而且我怀疑它是否是明天。
添加新运算符的问题是一个完全不同的问题。\\ b
问题。它源于语言设计师试图为开发人员带来的好处。如果词法分析器只是收集了最长的
可能的特殊字符串*之前*检查是否
特殊字符集合作为有效令牌，并声明
a语法错误，如果它没有，那么添加新操作符就没有问题。
该解决方案也相当不愉快：我们有点太习惯了b / b
能够将特殊字符操作符串在一起而不用
用空格分隔它们。同样，智能编辑器/ IDE
也会在这里提供帮助。
智能编辑器/ IDE也可以添加
来自Unicode
的众多数学符号中的任何一个都很容易设置：它可以根据开发人员的首选项进行调整，然后输入它们，当然可以正确地展示它们。
我想，我变老了，玩世不恭地放弃
期待任何一种非常激进的语言，实际上是
预测编辑器/ IDE以分担其工作份额。
John Roth
There is indeed a cost to adding new keywords and operators;
it''s possible that existing programs will break. It''s quite possible
to design a language where this wouldn''t happen, but Python is
not that language.
As it turns out, there is one very simple key to a language
with keywords where adding new ones won''t break existing
programs: put them in a lexically distinguishable namespace.
It happens that solution is quite unpleasant to work with -
unless it''s supported by a syntax aware editor/IDE. Someday
people will get over their attachment with being able to write
programs with any old text editor that happens to be lying
around, and being able to print their programs without
needing a special formatting program, but that day isn''t today,
and I doubt if it''s tomorrow.
The problem with adding new operators is a quite different
issue. It arises from the language designer trying to be too
nice to the developers. If the lexer simply collected the longest
possible string of special characters *before* checking if that
collection of special characters made a valid token, and declared
a syntax error if it didn''t, then there would be no difficulty with
adding new operators.
That solution is also fairly unpleasant: we''re a bit too used to
being able to string special character operators together without
separating them with white space. Again, an intelligent editor/IDE
would help here, too.
An intelligent editor/IDE would also make it possible to add
any of the numerous mathematical symbols from the Unicode
set easily: it could adjust for the developer''s preferences in
entering them, and would, of course, display them properly.
I am, I suppose, getting old and cynical enough to have quit
expecting anything quite so radical as a language that actually
expectes the editor/IDE to pull its share of the work.
John Roth
这篇关于使用@扩展Python语法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
