攻击神圣的Python牛 [英] Attack a sacred Python Cow
问题描述
大家好，
我是一位曾经常常参与半价游戏的大型粉丝。
comp.lang.python（很多潜伏，偶尔张贴）但有点
落后了一点。我刚刚在我的
博客上写了一篇令人沮丧的咆哮，我认为这对于
Python社区来说是一个更广泛的问题，可以在这里发帖讨论和考虑。
这不是火焰棒。我喜欢Python，我不会反对社区的b
。我也意识到我提出的问题之一就是
现在根本无法改变。我只是想分享一下我对Python的指导原则失误的想法，这个指导原则造成的伤害超过了好的IMO。所以无论如何，这里是帖子。
我已经完全相信至少有一个批评是我最喜欢的整体编程语言， Python，完全正确，并且公平。离编写Python代码还有一段时间之后，我昨晚一时兴起就打开了一些代码来获取一个想法的原型
我曾经有过。它正在游泳;我之前从未使用过的Python图像库看起来很快，直观，并且具有我需要的所有
功能。至于Python本身，好吧，我的心
仍然属于空白划界。所有基本的Python
编码都在我脑海中，就像我从未停止使用它们一样，或者像
我用这种语言编程了10年。
除了Classes之外。我在代码中添加了一些类，这些代码之前只是函数，而且你知道我做了什么 - 或者更确切地说，
忘了做什么？投入''自我''。在一些变量
访问之前，但更值得注意的是，在*每个方法的开头
参数列表。*这不能再被归咎于宿醉了来自
Java - 我写了更多的代码，最近在Python中编写的代码比使用
Java或任何其他OO语言编写的代码更多。更重要的是，每次我回到
Python后休息超过一周左右，我开始制作
这个''错误''再次。这种特征的长期理由是什么？
的语言？那个老Python最喜欢的，Explicit比
隐含更好。
对不起，但显性并不比隐含更好。
汇编程序是显式FFS。直观，聪明，可靠，预期，
精心设计的*隐含*行为是我使用高级语言的主要原因之一。隐藏垃圾收集旧物品
我？是的，拜托！
我曾经被Python疣咬过，我觉得它已经足够糟糕了。
花费一些力气提倡改变comp.lang .python（从来没有得到过b $ b来做PEP;部分懒惰，有些年轻且缺乏经验
足以让你被吓倒。也许是，或许。） />
以下不行，因为任何理智，合理的人都会期待：b
$ b＃博客代码，未经测试
A级（）：
def __eq __（self，obj）：
返回True
a = A（）
b = []
断言a == b
断言不是（a！= b）
第二个断言失败。为什么？因为编码__eq__，最明显的方法是使一个类具有基于相等的比较，所以从！=运算符中获取
。 ！=不是（默认情况下）
否定==的同义词（与其他语言不同）;不仅
Python会让你让它们意味着不同的东西，而不记录这个事实 - 它会积极地鼓励你这样做。
有一个令人沮丧的人数捍卫这个
（包括一个非常有名的Pythonista，认为它可能是
Effbot）。有些人冒昧地回避明确更好
比暗示：如果你想要！=工作，你应该该死的代码
__ne __！"
为什么，出于天堂的缘故，我应该在99.99％的用例中使用
（以及那些引用的0.01％实例）当时的论点只有
令我震惊的是远程引人注目）每个程序员都会想要__ $ _想要__ne__成为__eq__的逻辑否定？为什么，亲爱的Python，
你是否让我写出邪恶的Java式语言能力减少
样板来做你应该自己做的事情？
更重要的是，每个程序员都会无意识地期望它以这种方式工作，并且当它无法支付时，就会像我一样神秘而无法支付
这样做。不要告诉我RTFM并且不要告诉我要明确。我会
重复自己 - 如果我想要明确，我会使用C和
管理我自己的记忆非常感谢你。更好的是，我会明确地告诉你b $ b和图形发誓 - 对这种根深蒂固的设计感到沮丧
哲学疯狂困扰我最喜欢的语言。
我认为显式的真正问题比隐含的好，但是，b $ b虽然是，你可以看到其试图获得的基本事实
（这可能更好地表达了Ruby的更多模棱两可，
不那么可靠，但更有用的最小惊喜原则），在它的实际上是什么类型的b $ b meanginless主要用于
防御疣 - 不，我们会称它们为什么，一种语言
design * bugs *。
你看，问题是，
编程中没有任何明显的解释。这不是暗中做事的问题;这是一个隐含地做最明智的事情的问题。例如这个
python代码：
some_obj.some_meth（some_arg1，some_arg2）
隐含等效于
SomeClass.some_meth（some_obj，some_arg1，some_arg2）
反过来让我们自己作为对some_obj的引用，而Python'' s $ / $
OO模型快乐地假装它与Java相同，而实际上是一个表面看起来相同的
更智能的版本。
问题在于，每个方法的开头都有自己的明确要求是应该运送到
隐式类别。你应该明确，是 - 明确当
你想要*其他*行为，自我*不*是一个参数，
因为那更不寻常，不太可能的情况。
同样地，
a！= b
隐含等同于某物比如调用这个函数（可能
不正确，有一段时间因为我大量参与了这个
问题）：
def等于（a，b）：
如果hasattr（a，__ ne __）：返回a .__ ne __（b）
if hasattr（b，" __ne __"）：return b .__ ne __（a）
if hasattr（a，" __ cmp __"）：return not（a .__ cmp __（b）== 0）
如果hasattr（b，" __ cmp __"）：不返回（b .__ cmp __（a）== 0）
不返回（a是b）
对此没有任何明确的说法。我并不是在争论
隐瞒行为;我在争论将愚蠢的行为转变为更明智和更不令人惊讶的行为。
令人遗憾的是，有很多聪明的Python程序员会
以他们圣洁的十字军的名义来证明各种愚蠢的行为。
如果有一个改变我可能会对Python产生影响，那就是从禅宗那里得到那个该死的行。
Hi everyone,
I''m a big Python fan who used to be involved semi regularly in
comp.lang.python (lots of lurking, occasional posting) but kind of
trailed off a bit. I just wrote a frustration inspired rant on my
blog, and I thought it was relevant enough as a wider issue to the
Python community to post here for your discussion and consideration.
This is not flamebait. I love Python, and I''m not out to antagonise
the community. I also realise that one of the issues I raise is way
too ingrained to be changed now. I''d just like to share my thinking on
a misstep in Python''s guiding principles that has done more harm than
good IMO. So anyway, here''s the post.
I''ve become utterly convinced that at least one criticism leveled at
my favourite overall programming language, Python, is utterly true and
fair. After quite a while away from writing Python code, I started
last night on a whim to knock up some code for a prototype of an idea
I once had. It''s going swimmingly; the Python Image Library, which I''d
never used before, seems quick, intuitive, and with the all the
features I need for this project. As for Python itself, well, my heart
still belongs to whitespace delimitation. All the basics of Python
coding are there in my mind like I never stopped using them, or like
I''ve been programming in this language for 10 years.
Except when it comes to Classes. I added some classes to code that had
previously just been functions, and you know what I did - or rather,
forgot to do? Put in the ''self''. In front of some of the variable
accesses, but more noticably, at the start of *every single method
argument list.* This cannot be any longer blamed as a hangover from
Java - I''ve written a ton more code, more recently in Python than in
Java or any other OO language. What''s more, every time I go back to
Python after a break of more than about a week or so, I start making
this ''mistake'' again. The perennial justification for this ''feature''
of the language? That old Python favourite, "Explicit is better than
implicit."
I''m sorry, but EXPLICIT IS NOT NECESSARILY BETTER THAN IMPLICIT.
Assembler is explicit FFS. Intuitive, clever, dependable, expected,
well-designed *implicit* behaviour is one of the chief reasons why I
use a high level language. Implicitly garbage collect old objects for
me? Yes, please!
I was once bitten by a Python wart I felt was bad enough to raise and
spend some effort advocating change for on comp.lang.python (never got
around to doing a PEP; partly laziness, partly young and inexperienced
enough to be intimidated at the thought. Still am, perhaps.)
The following doesn''t work as any sane, reasonable person would
expect:
# Blog code, not tested
class A():
def __eq__(self, obj):
return True
a = A()
b = []
assert a == b
assert not (a != b)
The second assertion fails. Why? Because coding __eq__, the most
obvious way to make a class have equality based comparisons, buys you
nothing from the != operator. != isn''t (by default) a synonym for the
negation of == (unlike in, say, every other language ever); not only
will Python let you make them mean different things, without
documenting this fact - it actively encourages you to do so.
There were a disturbingly high number of people defending this
(including one quite renowned Pythonista, think it might have been
Effbot). Some had the temerity to fall back on "Explicit is better
than implict: if you want != to work, you should damn well code
__ne__!"
Why, for heaven''s sake, should I have to, when in 99.99% of use cases
(and of those 0.01% instances quoted in the argument at the time only
one struck me as remotely compelling) every programmer is going to
want __ne__ to be the logical negation of __eq__? Why, dear Python,
are you making me write evil Java-style language power reducing
boilerplate to do the thing you should be doing yourself anyway?
What''s more, every programmer is going to unconciously expect it to
work this way, and be as utterly as mystified as me when it fails to
do so. Don''t tell me to RTFM and don''t tell me to be explicit. I''ll
repeat myself - if I wanted to be explicit, I''d be using C and
managing my own memory thank you very much. Better yet, I''d explicitly
and graphically swear - swear in frustration at this entrenched design
philosophy madness that afflicts my favourite language.
I think the real problem with the explicit is better than implicit,
though, is that while you can see the underlying truth its trying to
get at (which is perhaps better expressed by Ruby''s more equivocal,
less dependable, but more useful Principle of Least Surprise), in its
stated form its actually kind of meanginless and is used mainly in
defence of warts - no, we''ll call them for what they are, a language
design *bugs*.
You see, the problem is, there''s no such thing of explict in
programming. Its not a question of not doing things implicitly; its a
question of doing the most sensible thing implicitly. For example this
python code:
some_obj.some_meth(some_arg1, some_arg2)
is implicitly equivalent to
SomeClass.some_meth(some_obj, some_arg1, some_arg2)
which in turn gives us self as a reference to some_obj, and Python''s
OO model merrily pretends its the same as Java''s when in fact is a
smarter version that just superficially looks the same.
The problem is that the explicit requirement to have self at the start
of every method is something that should be shipped off to the
implicit category. You should have to be explicit, yes - explicit when
you want the *other* behaviour, of self *not* being an argument,
because thats the more unusual, less likely case.
Likewise,
a != b
is implicitly equivalent to something like calling this function (may
not be correct, its a while since I was heavily involved in this
issue):
def equal(a, b):
if hasattr(a, "__ne__"): return a.__ne__(b)
if hasattr(b, "__ne__"): return b.__ne__(a)
if hasattr(a, "__cmp__"): return not (a.__cmp__(b) == 0)
if hasattr(b, "__cmp__"): return not (b.__cmp__(a) == 0)
return not (a is b)
There''s absolutely nothing explicit about this. I wasn''t arguing for
making behaviour implicit; I was arguing for changing the stupid
implict behaviour to something more sensible and less surprising.
The sad thing is there are plenty of smart Python programmers who will
justify all kinds of idiocy in the name of their holy crusade against
the implict.
If there was one change I could make to Python, it would be to get
that damn line out of the Zen.
推荐答案
7月24日，3：41 * pm，Jordan< jordanrastr ... @ gmail.comwrote：
On Jul 24, 3:41*pm, Jordan <jordanrastr...@gmail.comwrote:
大家好，
我是一个很狡猾的Python粉丝，过去常常参与半价游戏。
comp.lang.python（很多潜伏，偶尔张贴）但是有点
落后于位。我刚刚在我的
博客上写了一篇令人沮丧的咆哮，我认为这对于
Python社区来说是一个更广泛的问题，可以在这里发帖讨论和考虑。
这不是火焰棒。我喜欢Python，我不会反对社区的b
。我也意识到我提出的问题之一就是
现在根本无法改变。我只是想分享一下我对Python的指导原则失误的想法，这个指导原则造成的伤害超过了好的IMO。所以无论如何，这里是帖子。
我已经完全相信至少有一个批评是我最喜欢的整体编程语言， Python，完全正确，并且公平。离编写Python代码还有一段时间之后，我昨晚一时兴起就打开了一些代码来获取一个想法的原型
我曾经有过。它正在游泳;我之前从未使用过的Python图像库看起来很快，直观，并且具有我需要的所有
功能。至于Python本身，好吧，我的心
仍然属于空白划界。所有基本的Python
编码都在我脑海中，就像我从未停止使用它们一样，或者像
我用这种语言编程了10年。
除了Classes之外。我在代码中添加了一些类，这些代码之前只是函数，而且你知道我做了什么 - 或者更确切地说，
忘了做什么？投入''自我''。在一些变量
访问之前，但更值得注意的是，在*每个方法的开头
参数列表。*这不能再被归咎于宿醉了来自
Java - 我写了更多的代码，最近在Python中编写的代码比使用
Java或任何其他OO语言编写的代码更多。更重要的是，每次我回到
Python后休息超过一周左右，我开始制作
这个''错误''再次。这种特征的长期理由是什么？
的语言？那个老Python最喜欢的，Explicit比
隐含更好。
对不起，但显性并不比隐含更好。
汇编程序是显式FFS。直观，聪明，可靠，预期，
精心设计的*隐含*行为是我使用高级语言的主要原因之一。隐藏垃圾收集旧物品
我？是的，拜托！
我曾经被Python疣咬过，我觉得它已经足够糟糕了。
花费一些力气提倡改变comp.lang .python（从来没有得到过b $ b来做PEP;部分懒惰，有些年轻且缺乏经验
足以让你被吓倒。也许是，或许。） />
以下不行，因为任何理智，合理的人都会期待：b
$ b＃博客代码，未经测试
A级（）：
* def __eq __（self，obj）：
* *返回True
a = A（）
b = []
断言a == b
断言不是（a！= b）
第二个断言失败了。为什么？因为编码__eq__，最明显的方法是使一个类具有基于相等的比较，所以从！=运算符中获取
。 ！=不是（默认情况下）
否定==的同义词（与其他语言不同）;不仅
Python会让你让它们意味着不同的东西，而不记录这个事实 - 它会积极地鼓励你这样做。
有一个令人沮丧的人数捍卫这个
（包括一个非常有名的Pythonista，认为它可能是
Effbot）。有些人冒昧地回避明确更好
比暗示：如果你想要！=工作，你应该该死的代码
__ne __！"
为什么，出于天堂的缘故，我应该在99.99％的用例中使用
（以及那些引用的0.01％实例）当时的论点只有
令我震惊的是远程引人注目）每个程序员都会想要__ $ _想要__ne__成为__eq__的逻辑否定？为什么，亲爱的Python，
你是否让我写出邪恶的Java式语言能力减少
样板来做你应该自己做的事情？
更重要的是，每个程序员都会无意识地期望它以这种方式工作，并且当它无法支付时，就会像我一样神秘而无法支付
这样做。不要告诉我RTFM并且不要告诉我要明确。我会
重复自己 - 如果我想要明确，我会使用C和
管理我自己的记忆非常感谢你。更好的是，我会明确地告诉你b $ b和图形发誓 - 对这种根深蒂固的设计感到沮丧
哲学疯狂困扰我最喜欢的语言。
我认为显式的真正问题比隐含的好，但是，b $ b虽然是，你可以看到其试图获得的基本事实
（这可能更好地表达了Ruby的更多模棱两可，
不那么可靠，但更有用的最小惊喜原则），在它的实际上是什么类型的b $ b meanginless主要用于
防御疣 - 不，我们会称它们为什么，一种语言
design * bugs *。
你看，问题是，
编程中没有任何明显的解释。这不是暗中做事的问题;这是一个隐含地做最明智的事情的问题。例如这个
python代码：
some_obj.some_meth（some_arg1，some_arg2）
隐含等效于
SomeClass.some_meth（some_obj，some_arg1，some_arg2）
反过来让我们自己作为对some_obj的引用，而Python'' s $ / $
OO模型快乐地假装它与Java相同，而实际上是一个表面看起来相同的
更智能的版本。
问题在于，每个方法的开头都有自己的明确要求是应该运送到
隐式类别。你应该明确，是 - 明确当
你想要*其他*行为，自我*不*是一个参数，
因为那更不寻常，不太可能的情况。
同样地，
a！= b
隐含等同于某物比如调用这个函数（可能
不正确，有一段时间因为我大量参与了这个
问题）：
def等于（a，b）：
*如果hasattr（a，__ ne __）：返回a .__ ne __（b）
* if hasattr（b， " __ ne __"）：return b .__ ne __（a）
* if hasattr（a，" __ cmp __"）：return not（a .__ cmp __（b）== 0）
* if hasattr（b，" __ cmp __"）：return not（b .__ cmp __（a）== 0）
*不返回（a是b）
对此没有任何明确的说明。我并不是在争论
隐瞒行为;我在争论将愚蠢的行为转变为更明智和更不令人惊讶的行为。
令人遗憾的是，有很多聪明的Python程序员会
以他们圣洁的十字军的名义来证明各种愚蠢的行为。
如果有一个改变我可能会对Python产生影响，那就是从禅宗那里得到那个该死的线。
Hi everyone,
I''m a big Python fan who used to be involved semi regularly in
comp.lang.python (lots of lurking, occasional posting) but kind of
trailed off a bit. I just wrote a frustration inspired rant on my
blog, and I thought it was relevant enough as a wider issue to the
Python community to post here for your discussion and consideration.
This is not flamebait. I love Python, and I''m not out to antagonise
the community. I also realise that one of the issues I raise is way
too ingrained to be changed now. I''d just like to share my thinking on
a misstep in Python''s guiding principles that has done more harm than
good IMO. So anyway, here''s the post.
I''ve become utterly convinced that at least one criticism leveled at
my favourite overall programming language, Python, is utterly true and
fair. After quite a while away from writing Python code, I started
last night on a whim to knock up some code for a prototype of an idea
I once had. It''s going swimmingly; the Python Image Library, which I''d
never used before, seems quick, intuitive, and with the all the
features I need for this project. As for Python itself, well, my heart
still belongs to whitespace delimitation. All the basics of Python
coding are there in my mind like I never stopped using them, or like
I''ve been programming in this language for 10 years.
Except when it comes to Classes. I added some classes to code that had
previously just been functions, and you know what I did - or rather,
forgot to do? Put in the ''self''. In front of some of the variable
accesses, but more noticably, at the start of *every single method
argument list.* This cannot be any longer blamed as a hangover from
Java - I''ve written a ton more code, more recently in Python than in
Java or any other OO language. What''s more, every time I go back to
Python after a break of more than about a week or so, I start making
this ''mistake'' again. The perennial justification for this ''feature''
of the language? That old Python favourite, "Explicit is better than
implicit."
I''m sorry, but EXPLICIT IS NOT NECESSARILY BETTER THAN IMPLICIT.
Assembler is explicit FFS. Intuitive, clever, dependable, expected,
well-designed *implicit* behaviour is one of the chief reasons why I
use a high level language. Implicitly garbage collect old objects for
me? Yes, please!
I was once bitten by a Python wart I felt was bad enough to raise and
spend some effort advocating change for on comp.lang.python (never got
around to doing a PEP; partly laziness, partly young and inexperienced
enough to be intimidated at the thought. Still am, perhaps.)
The following doesn''t work as any sane, reasonable person would
expect:
# Blog code, not tested
class A():
* def __eq__(self, obj):
* * return True
a = A()
b = []
assert a == b
assert not (a != b)
The second assertion fails. Why? Because coding __eq__, the most
obvious way to make a class have equality based comparisons, buys you
nothing from the != operator. != isn''t (by default) a synonym for the
negation of == (unlike in, say, every other language ever); not only
will Python let you make them mean different things, without
documenting this fact - it actively encourages you to do so.
There were a disturbingly high number of people defending this
(including one quite renowned Pythonista, think it might have been
Effbot). Some had the temerity to fall back on "Explicit is better
than implict: if you want != to work, you should damn well code
__ne__!"
Why, for heaven''s sake, should I have to, when in 99.99% of use cases
(and of those 0.01% instances quoted in the argument at the time only
one struck me as remotely compelling) every programmer is going to
want __ne__ to be the logical negation of __eq__? Why, dear Python,
are you making me write evil Java-style language power reducing
boilerplate to do the thing you should be doing yourself anyway?
What''s more, every programmer is going to unconciously expect it to
work this way, and be as utterly as mystified as me when it fails to
do so. Don''t tell me to RTFM and don''t tell me to be explicit. I''ll
repeat myself - if I wanted to be explicit, I''d be using C and
managing my own memory thank you very much. Better yet, I''d explicitly
and graphically swear - swear in frustration at this entrenched design
philosophy madness that afflicts my favourite language.
I think the real problem with the explicit is better than implicit,
though, is that while you can see the underlying truth its trying to
get at (which is perhaps better expressed by Ruby''s more equivocal,
less dependable, but more useful Principle of Least Surprise), in its
stated form its actually kind of meanginless and is used mainly in
defence of warts - no, we''ll call them for what they are, a language
design *bugs*.
You see, the problem is, there''s no such thing of explict in
programming. Its not a question of not doing things implicitly; its a
question of doing the most sensible thing implicitly. For example this
python code:
some_obj.some_meth(some_arg1, some_arg2)
is implicitly equivalent to
SomeClass.some_meth(some_obj, some_arg1, some_arg2)
which in turn gives us self as a reference to some_obj, and Python''s
OO model merrily pretends its the same as Java''s when in fact is a
smarter version that just superficially looks the same.
The problem is that the explicit requirement to have self at the start
of every method is something that should be shipped off to the
implicit category. You should have to be explicit, yes - explicit when
you want the *other* behaviour, of self *not* being an argument,
because thats the more unusual, less likely case.
Likewise,
a != b
is implicitly equivalent to something like calling this function (may
not be correct, its a while since I was heavily involved in this
issue):
def equal(a, b):
* if hasattr(a, "__ne__"): return a.__ne__(b)
* if hasattr(b, "__ne__"): return b.__ne__(a)
* if hasattr(a, "__cmp__"): return not (a.__cmp__(b) == 0)
* if hasattr(b, "__cmp__"): return not (b.__cmp__(a) == 0)
* return not (a is b)
There''s absolutely nothing explicit about this. I wasn''t arguing for
making behaviour implicit; I was arguing for changing the stupid
implict behaviour to something more sensible and less surprising.
The sad thing is there are plenty of smart Python programmers who will
justify all kinds of idiocy in the name of their holy crusade against
the implict.
If there was one change I could make to Python, it would be to get
that damn line out of the Zen.
P.S.原谅这个错别字，它是以极端急速博客，然后只有
在发布之前快速校对和编辑。希望这一点
我没有因为你对我的尊重而减少了我的粗心大意:-)
P.S. Forgive the typos, it was blogged in extreme haste and then only
quickly proofread and edited before posting here. Hopefully the point
I''m making is not diminshed by your reduced respect for me as a result
of my carelessness :-)
7月24日，1：41 * pm，Jordan< jordanrastr ... @ gmail.comwrote：
On Jul 24, 1:41*pm, Jordan <jordanrastr...@gmail.comwrote:
大家好，
我是一个曾经常常参与过半价游戏的大型粉丝。
comp.lang.python（很多潜伏，偶尔发帖）但有点
落后了一点。我刚刚在我的
博客上写了一篇令人沮丧的咆哮，我认为这对于
Python社区来说是一个更广泛的问题，可以在这里发帖讨论和考虑。
Hi everyone,
I''m a big Python fan who used to be involved semi regularly in
comp.lang.python (lots of lurking, occasional posting) but kind of
trailed off a bit. I just wrote a frustration inspired rant on my
blog, and I thought it was relevant enough as a wider issue to the
Python community to post here for your discussion and consideration.
[...剪辑...]
+1，您的大部分意见。我今天早上也被__eq __ / __ ne__
问题所困扰。 :)
[...snip...]
+1 for most of your opinion. I was also bitten by the __eq__/__ne__
problem this morning. :)
Jordan写道：
Jordan wrote:
除了Classes之外。我在代码中添加了一些类，这些代码之前只是函数，而且你知道我做了什么 - 或者更确切地说，
忘了做什么？投入''自我''。在一些变量
访问之前，但更值得注意的是，在*每个方法的开头
参数列表。*这不能再被归咎于宿醉了来自
Java - 我写了更多的代码，最近在Python中编写的代码比使用
Java或任何其他OO语言编写的代码更多。更重要的是，每次我回到
Python后休息超过一周左右，我开始制作
这个''错误''再次。这种特征的长期理由是什么？
的语言？那个老Python最喜欢的，Explicit比
隐含更好。
Except when it comes to Classes. I added some classes to code that had
previously just been functions, and you know what I did - or rather,
forgot to do? Put in the ''self''. In front of some of the variable
accesses, but more noticably, at the start of *every single method
argument list.* This cannot be any longer blamed as a hangover from
Java - I''ve written a ton more code, more recently in Python than in
Java or any other OO language. What''s more, every time I go back to
Python after a break of more than about a week or so, I start making
this ''mistake'' again. The perennial justification for this ''feature''
of the language? That old Python favourite, "Explicit is better than
implicit."
你是否认真地认为Python是由无意识的应用程序设计的
发布了一系列幽默且有些自我贬低的观察结果
几年前到新闻组？
< / F>
Do you seriously think that Python is designed by mindless application
of a set of humorous and somewhat self-deprecating observations posted
to a newsgroup a number of years ago?
</F>
这篇关于攻击神圣的Python牛的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
