用户定义的运算符：一个非常适度的提议 [英] user-defined operators: a very modest proposal
问题描述
我最近一直在研究Python，我在一个
网页上看了一条评论，上面写着人们使用Python进行繁重的数学计算
真的希望他们可以定义自己的运营商。具体的
示例是定义外部产品。矩阵运算符。 （那里是b $ b甚至是一个PEP，编号211，关于这个。）
我给了它一些想法，并用Google搜索以前的讨论，
并提出了这个建议：
用户定义的运算符可以定义如下：] + [
我不是任何一种语言设计专家，但在我看来，这似乎是一种易于Python识别的语法。因为正方形
括号与通常的[]相反。订单，这看起来不应该是任何当前有效的代码
。并且方形括号，恕我直言，不会失败
低碳粉打印输出测试。 （一些早期的提案包括像
"〜+'这样的运算符，这些被认为太难阅读了。）
为了提高可读性，Python甚至可以强制要求
在用户定义的运算符的任何一侧都应该有空格。
我真的不认为这是必要的。 />
应该可以使用标点符号定义运算符，
字母数字，或两者：
] + [
]添加[
]外部* [
使用示例：
m = m0] * [ m1
m = m0] * [m1
m = m0]外* [m1
m = m0]外* [m1
我认为它的白色空间看起来好多了，但它并不可怕
没有空白区域。
此外，应该有一种方法来声明用户定义的
运算符使用什么样的优先级。 Python已经拥有许多具有不同优先级的运算符，我认为最好的方法就是指示新的
运算符的优先级应匹配哪个Python运算符： br $>
class MyExcellentMatrix（object）：
@precedence（''*''）
def __op_outer * __（self，right ）：
＃...做的东西...
我认为装饰器是设置优先级的好方法。
也许默认优先级应该是''+''。
应该支持增强形式：
] + = [
] * = [
]外* = [
例子：
m] * = [m0
m] * = [m0
m] outer * = [m0
m] outer * = [
或者我实际上已经提出了明智的建议，否则人们现在会解释为什么这个想法不好（我会学到一些东西）。无论哪种方式，
我期待你的评论。
参考文献：
元素/对象运算符
http://www.python.org/peps/pep- 0225.html
添加新的外部产品运营商
http://www.python.org/peps/pep-0211.html
-
Steve R 。黑斯廷斯Vita est
st***@hastings.org http://www.blarg.net/~steveha
I have been studying Python recently, and I read a comment on one
web page that said something like "the people using Python for heavy math
really wish they could define their own operators". The specific
example was to define an "outer product" operator for matrices. (There
was even a PEP, number 211, about this.)
I gave it some thought, and Googled for previous discussions about this,
and came up with this suggestion:
User-defined operators could be defined like the following: ]+[
I''m not any kind of language design expert, but this seems to me like a
syntax that would be easy for Python to recognize. Because the square
braces are reversed from the usual "[]" order, this should not look like
any currently-valid code. And square braces, IMHO, do not fail the
"low-toner printout" test. (Some earlier proposals included operators like
"~+" and these were deemed too hard to read.)
For improved readability, Python could even enforce a requirement that
there should be white space on either side of a user-defined operator.
I don''t really think that''s necessary.
It should be possible to define operators using punctuation,
alphanumerics, or both:
]+[
]add[
]outer*[
Examples of use:
m = m0 ]*[ m1
m = m0]*[m1
m = m0 ]outer*[ m1
m = m0]outer*[m1
It looks a lot better with the white space, I think, but it''s not horrible
without the white space.
Also, there should be a way to declare what kind of precedence the user-defined
operators use. Python already has lots of operators with different precedence,
and I think the best way is just to indicate which Python operator the new
operator''s precedence should match:
class MyExcellentMatrix(object):
@precedence(''*'')
def __op_outer*__(self, right):
# ...do stuff...
I think a decorator is a good way to set the precedence.
Perhaps the default precedence should be that of ''+''.
Augmented forms should be supported:
]+=[
]*=[
]outer*=[
Examples:
m ]*=[ m0
m]*=[m0
m ]outer*=[ m0
m]outer*=[
Either I actually have made a sensible suggestion, or else people will now
explain why this idea isn''t good (and I''ll learn something). Either way,
I look forward to your comments.
References:
Elementwise/Objectwise Operators
http://www.python.org/peps/pep-0225.html
Adding A New Outer Product Operator
http://www.python.org/peps/pep-0211.html
--
Steve R. Hastings "Vita est"
st***@hastings.org http://www.blarg.net/~steveha
推荐答案
2005年11月22日星期二13:48:05 -0800，Steve R. Hastings写道：
On Tue, 22 Nov 2005 13:48:05 -0800, Steve R. Hastings wrote:
用户定义的运算符可以定义如下：] + [
[snip]
使用示例：
m = m0] * [m1
m = M0] * [m1
在我看来，就像乘以两个列表一样。我必须看两次才能看到
操作数只是m0和m1而不是[m0]和[m1]。
m = m0] outer * [m1
m = m0] outer * [m1
User-defined operators could be defined like the following: ]+[
[snip]
Examples of use:
m = m0 ]*[ m1
m = m0]*[m1
That looks to me like multiplying two lists. I have to look twice to see
that the operands are merely m0 and m1 and not [m0] and [m1].
m = m0 ]outer*[ m1
m = m0]outer*[m1
这看起来很奇怪。
这是一个想法：Python已经支持无限数量
运算符，如果你用前缀表示法写它们：
inner_product（m0，m1）
outer_product（m0，m1 ）
等
这里有一些我不反对的语法，虽然那不是说
$ b $很多。在数学中，在一个圆圈内有一个加号的运算符，
在一个圆圈内乘以符号等。我们可以得到的最接近的ASCII
将是：
m0（+）m1
m0（*）m1
m0（ - ）m1
等等。
-
史蒂文。
That just looks weird.
Here is a thought: Python already supports an unlimited number of
operators, if you write them in prefix notation:
inner_product(m0, m1)
outer_product(m0, m1)
etc.
Here is some syntax that I don''t object to, although that''s not saying
much. In mathematics, there are operators of a plus sign within a circle,
multiply sign within a circle, etc. The closest we can get in plain ASCII
would be:
m0(+)m1
m0(*)m1
m0(-)m1
etc.
--
Steven.
如果您的提案已经实施，那么这是什么？代码是什么意思？
如果[1,2] + [3,4]！= [1,2,3,4]：提高TestFailed，''列表连接''
因为它包含''] + [''我认为它现在必须被解析为用户定义的
运算符，但此代码目前在Python中有意义。
（这段代码是我发现的第一个例子，Python 2.3'的test / test_types.py，所以它是
是实际代码）
我不相信Python需要用户定义的运算符，但是让我分享我的
糟糕的提议：类''Sm'中的每个unicode字符（符号，
数学）其价值我大于127的s可以用作用户定义的运算符。
调用的特殊方法取决于unicode字符的ord（），所以
调用__u2044__当源代码包含u''\\ N {FRACTION SLASH}''时。
无论采用什么替代语法来允许unicode标识符字符
都用纯ASCII键入也适用于键入用户定义的运算符。 " r"
和i运营商的版本当然会存在，如__ru2044__和
__iu2044__。
另外，为了容纳诸如u''\ {DOUBLE等运营商INTEGRAL}''，它们不是简单的一元或二元运算符，字符u'''N {NO BREAK SPACE}''将用于b / b
用于分离参数。必要时，括号将被添加到
删除歧义。这自然会导致像
\N {DOUBLE INTEGRAL}（y * x ** 2）\N {NO BREAK SPACE} dx \N {NO BREAK SPACE} dy
（对应于电话（y * x ** 2）.__ u222c __（dx，dy））显然很容易
爱，除了许多劣等编辑的小问题不会清楚地显示
显示\N {NO BREAK SPACE}字符。
我认为我想听听社区的一些项目我的想法是：
*我们是否给比较字符赋予特殊含义，比如
\ N {NEITHER LESS-THAN NOR GREATER-THAN}，或让用户定义他们用新的
方式？我们可以在对象上提供
def __u2279 __（self，other）：return not self .__ gt __（other）and other .__ gt __（self）
效果满足所有用户。
*我们是否立即实施运算符与非间距
标记的组合，还是推迟？如果我们实现它，我们是否允许组合使用
纯ASCII运算符，如
u''\ N {COMBINING LEFT RIGHT ARROW ABOVE} +''
或将其视为语法错误？ （顺便说一句，这个方法的名称将是
__u20e1u002b__，即使它可能很容易支持__u20e1x2b__，
__u2oe1add__和类似的方法名称）我们如何以及何时进行标准化
运算符结合多个非间距标记？
*内置类型应该支持哪些unicode运算符方法？
为集合实现__u222a__和__iu222a__是明智的，
很明显，但是__iu2206__对于整数和长期怎么样？
*应该是一些unicode数学符号是为文字保留的吗？
写\ u2205代替其他提议的
空集文字符号{ - }将是非常可取的。也许可以定义nullary运算符，
这样单独编写\ u2205与__u2205 __（）相同，即调用
无效函数，无论是否在本地定义，词汇，模块或
内置范围。
*我们是否支持So（符号，其他）类别中的字符？这样做不是
意味着阻止程序员使用像
\ un {HEAVY CONCAVE-POINTED BLACK RIGHTWARDS ARROW}这样的运算符。我们是谁？
为我们的用户做出这些选择？
Jeff
---- -BEGIN PGP SIGNATURE -----
版本：GnuPG v1.4.1（GNU / Linux）
iD8DBQFDg6EaJd01MZaTXX0RAn8NAJ0enTxrgz3KAS1otCMHFF DYkSKeQQCgmtyV
OvbivR1dPtSaT2 + bAMjK4jg =
= rK5l
----- END PGP SIGNATURE -----
If your proposal is implemented, what does this code mean?
if [1,2]+[3,4] != [1,2,3,4]: raise TestFailed, ''list concatenation''
Since it contains '']+['' I assume it must now be parsed as a user-defined
operator, but this code currently has a meaning in Python.
(This code is the first example I found, Python 2.3''s test/test_types.py, so it
is actual code)
I don''t believe that Python needs user-defined operators, but let me share my
terrible proposal anyway: Each unicode character in the class ''Sm'' (Symbol,
Math) whose value is greater than 127 may be used as a user-defined operator.
The special method called depends on the ord() of the unicode character, so
that __u2044__ is called when the source code contains u''\N{FRACTION SLASH}''.
Whatever alternate syntax is adopted to allow unicode identifier charactersto
be typed in pure ASCII will also apply to typing user-defined operators. "r"
and "i" versions of the operators will of course exist, as in __ru2044__ and
__iu2044__.
Also, to accomodate operators such as u''\N{DOUBLE INTEGRAL}'', which are not
simple unary or binary operators, the character u''\N{NO BREAK SPACE}'' will be
used to separate arguments. When necessary, parentheses will be added to
remove ambiguity. This leads naturally to expressions like
\N{DOUBLE INTEGRAL} (y * x**2) \N{NO BREAK SPACE} dx \N{NO BREAK SPACE} dy
(corresponding to the call (y*x**2).__u222c__(dx, dy)) which are clearly easy
to love, except for the small issue that many inferior editors will not clearly
display the \N{NO BREAK SPACE} characters.
Some items on which I think I''d like to hear the community''s ideas are:
* Do we give special meaning to comparison characters like
\N{NEITHER LESS-THAN NOR GREATER-THAN}, or let users define them in new
ways? We could just provide, on object,
def __u2279__(self, other): return not self.__gt__(other) and other.__gt__(self)
which would in effect satisfy all users.
* Do we immediately implement the combination of operators with nonspacing
marks, or defer it? If we implement it, do we allow the combination with
pure ASCII operators, as in
u''\N{COMBINING LEFT RIGHT ARROW ABOVE}+''
or treat it as a syntax error? (BTW the method name for this would be
__u20e1u002b__, even though it might be tempting to support __u20e1x2b__,
__u2oe1add__ and similar method names) How and when do we normalize
operators combined with more than one nonspacing mark?
* Which unicode operator methods should be supported by built-in types?
Implementing __u222a__ and __iu222a__ for sets is a no-brainer,
obviously, but what about __iu2206__ for integers and long?
* Should some of the unicode mathematical symbols be reserved for literals?
It would be greatly preferable to write \u2205 instead of the other proposed
empty-set literal notation, {-}. Perhaps nullary operators could be defined,
so that writing \u2205 alone is the same as __u2205__() i.e., callingthe
nullary function, whether it is defined at the local, lexical, module, or
built-in scope.
* Do we support characters from the category ''So'' (symbol, other)? Not
doing so means preventing programmers from using operators like
\u"n{HEAVY CONCAVE-POINTED BLACK RIGHTWARDS ARROW}". Who are we to
make those kinds of choices for our users?
Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDg6EaJd01MZaTXX0RAn8NAJ0enTxrgz3KAS1otCMHFF DYkSKeQQCgmtyV
OvbivR1dPtSaT2+bAMjK4jg=
=rK5l
-----END PGP SIGNATURE-----
Steve R. Hastings写道：
Steve R. Hastings wrote:
我最近一直在研究Python，我在一个页面上读了一条评论，上面写着人们使用Python来重数学
真的希望他们能定义自己的算子。具体的例子是定义外部产品。矩阵运算符。 （甚至还有一个PEP，编号211，关于这一点。）
我给了它一些想法，并用Google搜索以前的讨论，
并提出了这个建议：
用户定义的运算符可以定义如下：] + [
我不是任何一种语言设计专家，但在我看来这似乎是一个
Python易于识别的语法。因为正方形的支架与通常的[]相反。顺序，这应该看起来不像任何当前有效的代码。
[a，b] + [c]是两个列表的串联，还是包含a和b] +的单个双元素
方形括号，恕我直言，低碳粉打印输出不会失败。测试。
I have been studying Python recently, and I read a comment on one
web page that said something like "the people using Python for heavy math
really wish they could define their own operators". The specific
example was to define an "outer product" operator for matrices. (There
was even a PEP, number 211, about this.)
I gave it some thought, and Googled for previous discussions about this,
and came up with this suggestion:
User-defined operators could be defined like the following: ]+[
I''m not any kind of language design expert, but this seems to me like a
syntax that would be easy for Python to recognize. Because the square
braces are reversed from the usual "[]" order, this should not look like
any currently-valid code.
Is [a,b]+[c] the concatenation of two lists, or a single two-element
list containing a and b ]+[ c?
And square braces, IMHO, do not fail the "low-toner printout" test.
他们这样做。就在昨天，我打印了一些代码，其中一些
方括号没有显示出来。
They do. Just yesterday I printed some code in which some of the
square braces didn''t show up.
这篇关于用户定义的运算符：一个非常适度的提议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
