死于元组！ [英] Death to tuples!

问题描述

似乎元组和列表之间的区别慢慢消失了。我们称之为元组拆包在赋值的任一侧使用

的列表和值侧的迭代器都可以正常工作。 IIRC，

申请过去要求第二个参数是一个元组;它现在是

接受序列，并且已经被折旧以支持* args，其中
不仅接受序列而且接受迭代器。


语言中是否有任何地方仍然需要元组代替

序列，除了用作字典键外？


如果不是，那么它''不清楚元组作为一种独特的数据类型仍然是语言的目的。在这种情况下，我认为考虑废除元组是合适的。嗯，不是真的：只是改变他们的预期用途，改变名称注意，并且

调整实现以符合这一点。

新的预期用途是作为不可变序列类型，而不是

轻量级C结构。用于表示这种新用途的新名称 -

跟随集合类型的脚步 - 是冻结列表。

对实现的更改将添加任何非变异方法

列表到元组，这似乎意味着索引和计数。


删除元组类型显然是Py3K操作。现在可以添加冻结清单

。在Py3K是一个有趣的问题之前，我们可以将元组作为
frozenlist的别名。


< mike

- -

Mike Meyer< mw*@mired.org> http://www.mired.org/home/mwm/

独立的WWW / Perforce / FreeBSD / Unix顾问，电子邮件以获取更多信息。

It seems that the distinction between tuples and lists has slowly been
fading away. What we call "tuple unpacking" works fine with lists on
either side of the assignment, and iterators on the values side. IIRC,
"apply" used to require that the second argument be a tuple; it now
accepts sequences, and has been depreciated in favor of *args, which
accepts not only sequences but iterators.

Is there any place in the language that still requires tuples instead
of sequences, except for use as dictionary keys?

If not, then it''s not clear that tuples as a distinct data type still
serves a purpose in the language. In which case, I think it''s
appropriate to consider doing away with tuples. Well, not really: just
changing their intended use, changing the name to note that, and
tweaking the implementation to conform to this.

The new intended use is as an immutable sequence type, not a
"lightweight C struct". The new name to denote this new use -
following in the footsteps of the set type - is "frozenlist". The
changes to the implementation would be adding any non-mutating methods
of list to tuple, which appears to mean "index" and "count".

Removing the tuple type is clearly a Py3K action. Adding frozenlist
could be done now. Whehter or not we could make tuple an alias for
frozenlist before Py3K is an interesting question.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

推荐答案

Mike Meyer< mw * @ mired.org>写道：

Mike Meyer <mw*@mired.org> writes:

新的预期用途是作为一个不可变的序列类型，而不是一个轻量级C结构。用于表示这种新用途的新名称 -
跟随集合类型的脚步 - 是冻结列表。对实现的改变将是向列表添加列表的任何非变异方法，这似乎意味着索引。和计数。

The new intended use is as an immutable sequence type, not a
"lightweight C struct". The new name to denote this new use -
following in the footsteps of the set type - is "frozenlist". The
changes to the implementation would be adding any non-mutating methods
of list to tuple, which appears to mean "index" and "count".

我喜欢这个。我还注意到元组早于类。这些天使用C $ struct的合适方法通常是__slots__类

实例。

I like this. I also note that tuples predated classes. The
appropriate way to do a C struct these days is often as a class
instance with __slots__.

Mike Meyer写道：

Mike Meyer wrote:

似乎元组和列表之间的区别已逐渐消失。我们称之为元组拆包适用于赋值任一侧的列表和值侧的迭代器。 IIRC，
申请过去要求第二个参数是一个元组;它现在接受序列，并且已被折旧以支持* args，它不仅接受序列而且接受迭代器。

语言中是否还有任何地方仍需要元组而不是序列，除了用作字典键？

It seems that the distinction between tuples and lists has slowly been
fading away. What we call "tuple unpacking" works fine with lists on
either side of the assignment, and iterators on the values side. IIRC,
"apply" used to require that the second argument be a tuple; it now
accepts sequences, and has been depreciated in favor of *args, which
accepts not only sequences but iterators.

Is there any place in the language that still requires tuples instead
of sequences, except for use as dictionary keys?

字符串的％运算符。在参数列表中。


def __setitem __（自我，（行，列），值）：

...

The % operator for strings. And in argument lists.

def __setitem__(self, (row, column), value):
...

Mike Meyer启发我们：

Mike Meyer enlightened us with:

除了用作词典键之外，语言中是否仍然需要元组而不是序列？ ？


任何不可改变的数字序列。例如，一对

的坐标。或者该值的值和权重。

如果没有，那么不清楚元组作为一种独特的数据类型
仍然在语言中起作用。在这种情况下，我认为考虑废除元组是合适的。


我真的不同意。有无数的例子，添加或从列表中删除元素只是不正确。

新的预期用途是作为一个不可变的序列类型，而不是
轻量级C结构。

Is there any place in the language that still requires tuples
instead of sequences, except for use as dictionary keys?
Anything that''s an immutable sequence of numbers. For instance, a pair
of coordinates. Or a value and a weight for that value.
If not, then it''s not clear that tuples as a distinct data type
still serves a purpose in the language. In which case, I think it''s
appropriate to consider doing away with tuples.
I really disagree. There are countless examples where adding or
removing elements from a list just wouldn''t be right.
The new intended use is as an immutable sequence type, not a
"lightweight C struct".

它真的是一样的。一个轻量级的元素列表，其中每个元素都有自己的含义，既是一个不可变的序列，也是一个轻量级的C struct。


Sybren

-

世界的问题是愚蠢。并不是说应该对愚蠢的死刑进行处罚，但为什么我们不要仅仅拿掉

安全标签来解决问题呢？ br />
Frank Zappa

It''s the same, really. A lightweight list of elements, where each
element has its own meaning, is both an immutable sequence as well as
a lightweight C struct.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don''t we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

这篇关于死于元组！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！