允许零维下标 [英] Allowing zero-dimensional subscripts
问题描述
您好，
我发现我需要对Python语法进行一些小改动。我想b / b
想听听你对它的看法。
两行：
目前，表达式为x []"是语法错误。
我建议将它评估为x [（）]，就像x [a，b]一样。
评估为x [（a，b）]现在。
再说几句话：目前，一个对象可以用几个元素下标，用逗号分隔。它被评估为对象是由包含这些元素的元组下标的
。我建议
对象也可以订阅，根本没有任何元素，并且它将被评估为
，好像该对象是由空元组下标。
它没有向后兼容性，因为我们正在处理
当前非法语法的合法化。
它是与当前语法一致。考虑到这些
身份目前持有：
x [i，j，k]< - > x [（i，j，k）]
x [i，j]< - > x [（i，j）]
x [i，]< - > x [（i，）]
x [i]< - > x [（i）]
我建议下一个身份也会成立：
x []< - > x [（）]
我需要这个，以便能够很好地引用零维数组
。在NumPy中，您可以使用不同数量的
维度的数组。为了引用二维数组中的值，
你写了一个[i，j]。为了引用一维
数组中的值，你写一个[i]。你也可以有一个零维数组，
，它包含一个值（一个标量）。要引用它的值，你现在需要写一个[（）]
，这是意想不到的 - 用户可能不知道
甚至知道当他写一个[i] ，j]他构造了一个元组，所以他不会猜测[（）]语法。如果我的建议被接受，那么他将能够写一个[]以便按预期引用该值。即使在没有更换NumPy包的情况下也可以工作！
在NumPy的正常使用中，你通常不会遇到
零维数组。但是，我正在设计另一个用于管理多维数据数组的
库。其目的类似于电子表格的分析 - 分析数据并保留计算源与目的地之间的关系。在这样的环境中，你可能会有很多多维数组 - 例如，几个时间段内几种产品的销售额b / b $ b。但是你可能还有很多零维数组，也就是单个数值 - 例如，
所得税。我希望对零维数组的访问与对多维数组的访问一致。只需使用
零维数组的名称来获取它的值就不会起作用 - 数组及其包含的值必须要区分。
我试图改变CPython来支持它，这很容易。
你可以在这里看到当前SVN的差异：
http://python.pastebin.com/768317
测试套件按预期通过，无需更改。我没有包含
差异的自动生成文件。我对AST几乎一无所知，所以如果熟悉AST的人会检查
，看看我是否正确，我会赞赏它。但它似乎确实有效。
嗯，您对此有何看法？
祝您有个美好的一天，
Noam Raphael
< sp ******* @ gmail.com>在消息中写道
news：11 ********************* @ i40g2000cwc.googlegro ups.com ...你好，
我发现我需要对Python语法进行一些小改动。我想听听你对它的看法。
分两行：
目前，表达式x []是一个语法错误。
我建议它将被评估为x [（）]，就像x [a，b]一样。被评估为x [（a，b）]现在。
再说几句话：目前，一个对象可以用几个
元素下标，用逗号分隔。它被评估为对象是由包含这些元素的元组下标的。
这不是''好像''。 ''，b''*是*一个元组，对象*是*
元组的子脚本。
在非空元组周围添加（）不会增加任何内容除了一点噪音。
dis（compile（''x [a，b]''，' '''，'''eval''））
0 0 LOAD_NAME 0（x）
3 LOAD_NAME 1（a）
6 LOAD_NAME 2（b）
9 BUILD_TUPLE 2
12 BINARY_SUBSCR
13 RETURN_VALUE dis（编译（''x [（a，b）]''，'' ''，''eval''））
0 0 LOAD_NAME 0（x）
3 LOAD_NAME 1（a ）
6 LOAD_NAME 2（b）
9 BUILD_TUPLE 2
12 BINARY_SUBSCR
13 RETURN_VALUE
仅在优先分组时需要非空元组的parens，t他/ b
与（a + b）* c相同。
我建议
对象也可以订阅，没有任何元素，它会
被评估为对象是由空元组下标。
同样，对它没有好像。你建议在一个元组周围的元数没有在这个特定的上下文中是可选的。
虽然在逻辑上可行，但Guido决定元组nothings应该*总是*
与其他nothings不同，并通过
括号从周围的代码中引出。原因是避免歧义和捕捉错误。我认为
这是一个不错的选择。
Terry Jan Reedy
您好，
Terry Reedy写道：再说几句：目前，一个对象可以通过以下方式订阅几个元素，用逗号分隔。它被评估为对象是由包含这些元素的元组下标。
它不是''好像''。 ''，b''*是一个元组，对象*由一个元组表示。
在非空元组周围添加（）除了一点噪音之外什么都不添加。
这不一定重要，但从技术上讲，它不是元组。
1,2在x [1,2]中不是根据与x = 1,2中的/ b $ b相同的规则进行评估。 - 例如，你可以拥有x [1,2：3：4，...，5]，其中
不是方括号之外的合法元组 - 事实上，它甚至不是合法的内部合法：x [（1,2：3：4，...，5）]是不合法的语法。
Noam
< sp *******@gmail.com>在消息中写道
news：11 ********************* @ f6g2000cwb.googlegrou ps.com ...Terry Reedy写道：>再说几句话：目前，一个对象可以通过一些对象下载
>元素，以逗号分隔。它被评估为对象是
>由包含这些元素的元组下标。
它不是好像。 ''，b''*是一个元组，对象*由一个
元组代表
。
在非空元组周围添加（）除了一点点之外什么都不添加噪音。
它并不一定重要，但从技术上讲，它不是一个元组。
告诉编译器。这里是代码。
dis（compile（''x [a，b]''，'' ''，''eval''））
0 0 LOAD_NAME 0（x）
3 LOAD_NAME 1（a）
6 LOAD_NAME 2（b）
9 BUILD_TUPLE 2
12 BINARY_SUBSCR
13 RETURN_VALUE dis（编译（''x = a，b''，''''，' 'single''））
1 0 LOAD_NAME 0（a）
3 LOAD_NAME 1（b）
6 BUILD_TUPLE 2
9 STORE_NAME 2（x）
12 LOAD_CONST 0（无）
15 RETURN_VALUE
构建元组的完全相同的代码a，b。
1,2在x [1,2]中根据与x = 1,2中的相同规则进行评估。
dis（compile（''x [1,2]''，''''，''eval''））
0 0 LOAD_NAME 0（x）
3 LOAD_CONST 2（（1,2））
6 BINARY_SUBSCR
7 RETURN_VALUE dis（编译（''x = 1,2''，''''，' 'single''））
1 0 LOAD_CONST 3（（1,2））
3 STORE_NAME 0（x）
6 LOAD_CONST 2（无）
9 RETURN_VALUE
完全相同的元组文字。元组规则是相同的。
- 例如，你可以有x [1,2：3：4，...，5]，这是
方括号之外的合法元组 - 事实上，它甚至不是合法的内容：x [（1,2：3：4，...，5）]"是不合法的语法。
是的，切片和省略号文字只在括号内直接有效。
这绝对值得了解关于他们，这是一个地方
里面的元组不能用括号括起来。但是一旦它们被接受，
切片和省略号对象就像任何
其他的那样产生元组的成员。
dis（编译（&） ; x [1,2：3：4，...，5]"，''''，''eval''））
0 0 LOAD_NAME 0（x）
3 LOAD_CONST 0（1）
6 LOAD_CONST 1（2）
9 LOAD_CONST 2（3 ）
12 LOAD_CONST 3（4）
15 BUILD_SLICE 3
18 LOAD_CONST 4（省略号）
21 LOAD_CONST 5（5）
24 BUILD_TUPLE 4
27 BINARY_SUBSCR
28 RETURN_VALUE
所以我做没有看到任何点或有用的说元组下标是
而不是它是什么。
Terry Jan Reedy
Hello,
I discovered that I needed a small change to the Python grammar. I
would like to hear what you think about it.
In two lines:
Currently, the expression "x[]" is a syntax error.
I suggest that it will be evaluated like "x[()]", just as "x[a, b]" is
evaluated like "x[(a, b)]" right now.
In a few more words: Currently, an object can be subscripted by a few
elements, separated by commas. It is evaluated as if the object was
subscripted by a tuple containing those elements. I suggest that an
object will also be subscriptable with no elements at all, and it will
be evaluated as if the object was subscripted by an empty tuple.
It involves no backwards incompatibilities, since we are dealing with
the legalization of a currently illegal syntax.
It is consistent with the current syntax. Consider that these
identities currently hold:
x[i, j, k] <--> x[(i, j, k)]
x[i, j] <--> x[(i, j)]
x[i, ] <--> x[(i, )]
x[i] <--> x[(i)]
I suggest that the next identity will hold too:
x[] <--> x[()]
I need this in order to be able to refer to zero-dimensional arrays
nicely. In NumPy, you can have arrays with a different number of
dimensions. In order to refer to a value in a two-dimensional array,
you write a[i, j]. In order to refer to a value in a one-dimensional
array, you write a[i]. You can also have a zero-dimensional array,
which holds a single value (a scalar). To refer to its value, you
currently need to write a[()], which is unexpected - the user may not
even know that when he writes a[i, j] he constructs a tuple, so he
won''t guess the a[()] syntax. If my suggestion is accepted, he will be
able to write a[] in order to refer to the value, as expected. It will
even work without changing the NumPy package at all!
In the normal use of NumPy, you usually don''t encounter
zero-dimensional arrays. However, I''m designing another library for
managing multi-dimensional arrays of data. Its purpose is similiar to
that of a spreadsheet - analyze data and preserve the relations between
a source of a calculation and its destination. In such an environment
you may have a lot of multi-dimensional arrays - for example, the sales
of several products over several time periods. But you may also have a
lot of zero-dimensional arrays, that is, single values - for example,
the income tax. I want the access to the zero-dimensional arrays to be
consistent with the access to the multi-dimensional arrays. Just using
the name of the zero-dimensional array to obtain its value isn''t going
to work - the array and the value it contains have to be distinguished.
I have tried to change CPython to support it, and it was fairly easy.
You can see the diff against the current SVN here:
http://python.pastebin.com/768317
The test suite passes without changes, as expected. I didn''t include
diffs of autogenerated files. I know almost nothing about the AST, so I
would appreciate it if someone who is familiar with the AST will check
to see if I did it right. It does seem to work, though.
Well, what do you think about this?
Have a good day,
Noam Raphael
<sp*******@gmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...Hello,
I discovered that I needed a small change to the Python grammar. I
would like to hear what you think about it.
In two lines:
Currently, the expression "x[]" is a syntax error.
I suggest that it will be evaluated like "x[()]", just as "x[a, b]" is
evaluated like "x[(a, b)]" right now.
In a few more words: Currently, an object can be subscripted by a few
elements, separated by commas. It is evaluated as if the object was
subscripted by a tuple containing those elements.
It is not ''as if''. ''a,b'' *is* a tuple and the object *is* subcripted by a
tuple.
Adding () around the non-empty tuple adds nothing except a bit of noise.
dis(compile(''x[a,b]'','''',''eval'')) 0 0 LOAD_NAME 0 (x)
3 LOAD_NAME 1 (a)
6 LOAD_NAME 2 (b)
9 BUILD_TUPLE 2
12 BINARY_SUBSCR
13 RETURN_VALUE dis(compile(''x[(a,b)]'','''',''eval''))
0 0 LOAD_NAME 0 (x)
3 LOAD_NAME 1 (a)
6 LOAD_NAME 2 (b)
9 BUILD_TUPLE 2
12 BINARY_SUBSCR
13 RETURN_VALUE
Parens around non-empty tuples are only needed for precedence grouping, the
same as in (a+b)*c.
I suggest that an
object will also be subscriptable with no elements at all, and it will
be evaluated as if the object was subscripted by an empty tuple.
Again, there would be no ''as if'' about it. You are suggesting that the
parens around a tuple nothing be optional in this particular context.
While logically possible, Guido decided that tuple nothings should *always*
be distinguished from other nothings and set off from surrounding code by
parentheses. The reason is to avoid ambiguity and catch errors. I think
this is overall a good choice.
Terry Jan Reedy
Hello,
Terry Reedy wrote:In a few more words: Currently, an object can be subscripted by a few
elements, separated by commas. It is evaluated as if the object was
subscripted by a tuple containing those elements.
It is not ''as if''. ''a,b'' *is* a tuple and the object *is* subcripted by a
tuple.
Adding () around the non-empty tuple adds nothing except a bit of noise.
It doesn''t necessarily matter, but technically, it is not "a tuple".
The "1, 2" in "x[1, 2]" isn''t evaluated according to the same rules as
in "x = 1, 2" - for example, you can have "x[1, 2:3:4, ..., 5]", which
isn''t a legal tuple outside of square braces - in fact, it even isn''t
legal inside parens: "x[(1, 2:3:4, ..., 5)]" isn''t legal syntax.
Noam
<sp*******@gmail.com> wrote in message
news:11*********************@f6g2000cwb.googlegrou ps.com...Terry Reedy wrote:> In a few more words: Currently, an object can be subscripted by a few
> elements, separated by commas. It is evaluated as if the object was
> subscripted by a tuple containing those elements.
It is not ''as if''. ''a,b'' *is* a tuple and the object *is* subcripted
by a
tuple.
Adding () around the non-empty tuple adds nothing except a bit of noise.
It doesn''t necessarily matter, but technically, it is not "a tuple".
Tell that to the compiler. Here the code again.
dis(compile(''x[a,b]'','''',''eval'')) 0 0 LOAD_NAME 0 (x)
3 LOAD_NAME 1 (a)
6 LOAD_NAME 2 (b)
9 BUILD_TUPLE 2
12 BINARY_SUBSCR
13 RETURN_VALUE dis(compile(''x=a,b'','''',''single'')) 1 0 LOAD_NAME 0 (a)
3 LOAD_NAME 1 (b)
6 BUILD_TUPLE 2
9 STORE_NAME 2 (x)
12 LOAD_CONST 0 (None)
15 RETURN_VALUE
The same exact code to build the tuple a,b.
The "1, 2" in "x[1, 2]" isn''t evaluated according to the same rules as
in "x = 1, 2" dis(compile(''x[1,2]'','''',''eval'')) 0 0 LOAD_NAME 0 (x)
3 LOAD_CONST 2 ((1, 2))
6 BINARY_SUBSCR
7 RETURN_VALUE dis(compile(''x=1,2'','''',''single'')) 1 0 LOAD_CONST 3 ((1, 2))
3 STORE_NAME 0 (x)
6 LOAD_CONST 2 (None)
9 RETURN_VALUE
Same exact tuple literal. The tuple rules are the same.
- for example, you can have "x[1, 2:3:4, ..., 5]", which
isn''t a legal tuple outside of square braces - in fact, it even isn''t
legal inside parens: "x[(1, 2:3:4, ..., 5)]" isn''t legal syntax.
Yes, slice and ellipsis literals are only valid directly inside brackets.
And it is definitely worth knowing about them and that this is one place
where a tuple cannot be parenthesized. But once they are accepted, the
slice and ellipsis objects are members of the resulting tuple like any
other.
dis(compile("x[1, 2:3:4, ..., 5]", '''',''eval''))
0 0 LOAD_NAME 0 (x)
3 LOAD_CONST 0 (1)
6 LOAD_CONST 1 (2)
9 LOAD_CONST 2 (3)
12 LOAD_CONST 3 (4)
15 BUILD_SLICE 3
18 LOAD_CONST 4 (Ellipsis)
21 LOAD_CONST 5 (5)
24 BUILD_TUPLE 4
27 BINARY_SUBSCR
28 RETURN_VALUE
So I do not see any point or usefulness in saying that a tuple subcript is
not what it is.
Terry Jan Reedy
这篇关于允许零维下标的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
