len（）和PEP 3000 [英] len() and PEP 3000
问题描述
Python 3000 PEP中没有提到函数len（）。
我建议至少列表， tupples，sets，dictionaries和strings
得到len（）方法。我认为len函数可以保留，删除它
会破坏很多代码。但是添加这个方法会很有用。
是的，我知道，我可以调用.__ len __（）但这很难看。
我已经阅读了len函数的FAQ：
http://www.python.org/doc/faq/genera。 ..reg-len-list
-
ThomasGüttler， http://www.thomas-guettler.de/ http://www.tbz-pariv.de/
电子邮件：guettli（*）thomas-guettler + de
垃圾邮件捕手： ni ************** @ thomas-guettler.de
Thomas Guettler写道：
我建议至少是lis ts，tupples，sets，dictionaries和
字符串获取len（）方法。
为什么？
我认为len函数可以保留，删除它会破坏很多/>
代码。但是添加方法会很有用。
是的，我知道，我可以调用.__ len __（），但这很难看。
这就是len（）的用途。
问候，
Bj ？$
-
BOFH借口＃281：
协同定位器无法验证框架 - 中继网关到ISDN
服务器。
Bjoern Schliessmann schrieb：
Thomas Guettler写道：
我建议至少列表，tupples，set，dictionaries和
字符串得到len（ ） 方法。
为什么？
Pro：因为它使API更加单调，并且与现在和将来存在的所有其他OO语言更加一致。它还可以帮助任何
写入和未写入的IDE，通过
自动完成提供方法。它结束了与Java / C ++ / C＃等无休止的辩论和
新手Python程序员关于这个小问题。
Contra：同时拥有__len__（用于提供通用函数由
对偶）和API中的len是令人不愉快的。
但也许可以删除所有__special__方法并使用装饰器来
表示方法和函数之间的对偶性？
类M：
@generic
def foo（self）：
print" foo"
>> foo （M（））#equals M（）。foo（）
" foo"
因为我们在这。为什么不放弃__add __，__ radd __，
__plus__等等：
等级M：
def二进制+（自我，其他）：＃替换__add__
...
def r_binary +（自我，其他）：＃替换__radd__
...
def anary +（self，other）：＃替换__plus__
...
Kay Schluehr写道：
Pro：因为它使API更加单调且更加一致
与所有其他OO语言存在现在和将来。它还可以帮助任何书面和未写入的IDE通过
自动完成提供方法。它结束了与Java / C ++ / C＃等无休止的辩论和
新手Python程序员关于这个小问题。
Contra：它使API与其他一些OO语言更加一致
并将焦点从python方式移开它的方式总是
已完成。
问候，
Bj？rn
-
BOFH借口＃308：
CD-ROM服务器需要重新校准
Hi,
The function len() is not mentioned in the Python 3000 PEPs.
I suggest that at least lists, tupples, sets, dictionaries and strings
get a len() method. I think the len function can stay, removing it
would break to much code. But adding the method, would bu usefull.
Yes, I know, that I can call .__len__() but that is ugly.
I have read the FAQ to the len function:
http://www.python.org/doc/faq/genera...r-e-g-len-list
--
Thomas Güttler, http://www.thomas-guettler.de/ http://www.tbz-pariv.de/
E-Mail: guettli (*) thomas-guettler + de
Spam Catcher: ni**************@thomas-guettler.de
Thomas Guettler wrote:
I suggest that at least lists, tupples, sets, dictionaries and
strings get a len() method.Why?
I think the len function can stay, removing it would break to much
code. But adding the method, would bu usefull.
Yes, I know, that I can call .__len__() but that is ugly.That''s what len() is for.
Regards,
Bj?rn
--
BOFH excuse #281:
The co-locator cannot verify the frame-relay gateway to the ISDN
server.
Bjoern Schliessmann schrieb:
Thomas Guettler wrote:
I suggest that at least lists, tupples, sets, dictionaries and
strings get a len() method.
Why?Pro: Because it makes the API more monotonous and more aligned with all
other OO languages that exist now and in future. It also helps any
written and unwritten IDE providing a method by means of
autocompletion. It ends endless debates with Java/C++/C# etc. and
newbie Python programmers about this minor issue.
Contra: Having both __len__ ( for providing a generic function by
duality ) and len in the API is unpleasant.
But maybe one can drop all __special__ methods and use a decorator to
express duality between methods and functions?
class M:
@generic
def foo(self):
print "foo"
>>foo(M()) # equals M().foo()
"foo"
And since we are at it. Why not also dropping __add__, __radd__,
__plus__ etc. for:
class M:
def binary+(self, other): # replaces __add__
...
def r_binary+(self, other): # replaces __radd__
...
def unary+(self, other): # replaces __plus__
...
Kay Schluehr wrote:
Pro: Because it makes the API more monotonous and more aligned
with all other OO languages that exist now and in future. It also
helps any written and unwritten IDE providing a method by means of
autocompletion. It ends endless debates with Java/C++/C# etc. and
newbie Python programmers about this minor issue.Contra: It makes the API more aligned with some other OO languages
and moves the focus from "the python way" to "the way it''s always
been done".
Regards,
Bj?rn
--
BOFH excuse #308:
CD-ROM server needs recalibration
这篇关于len（）和PEP 3000的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
