理解自我 [英] understanding self

问题描述

在课堂上使用''self''似乎非常简单。我的好奇心是

为什么我必须使用它。难道不是暗示吗？如果我创建一个实例

''human''称为''bruce''并且调用方法''blink''为什么我必须

将布鲁斯传递给方法例如


类人类：

...代码

def blink（自我，时间）：

for i in range（times）：

if self.eye_is_closed：

self.eye_open（）

self.eye_close（ ）

else：

self.eye_close（）

self.eye_open（）

def eye_open（self） ：

...代码

def eye_close（个体经营）：

...代码

bruce =人类（）

bruce.blink（5）


眨眼是布鲁斯的一种方法，因为布鲁斯是人类的一个例子。

读这个愚蠢的代码，我可以理解如果自己是什么，

不包括在内。任何人都可以告诉我为什么我们有自己？


顺便说一下..几个月的python和我是程序员的10倍我是

与vb

v / r

布鲁斯

解决方案

bruce stockwell写道：

在课堂上使用''self''似乎非常简单。我的好奇心是为什么我必须使用它。难道不应该暗示吗？

问题在于隐含的自我比明确的自我更难以读取

当实例属性

与全局属性或内置属性同名时，''self''也打开了歧义的大门。


让'在一个假设的Python变体中看一个例子，其中''self''

暗示 -


class eye：

def open（下）：

＃在这里做东西


def close（下）：

＃在这里做东西


def blink（下）：

如果关闭：

开放（哪个）

关闭（其中）

其他：

关闭（其中）

开放（其中）


e = eye（）

e.blink（''right''）


但是等待 - open（）是一个过时的内置函数，用于打开a文件。

eye.blink（）应该做什么 - 打开和关闭右眼，或者打开一个

文件名字叫''对''??如果它是前者，那么如果你想*打开那个文件，你会怎么做？b $ b怎么办？如果它是后者，那么当下一个版本的Python出现并且open（）从内置函数中移除后，会发生什么？b $ b？


即使没有这些名称空间冲突，当你阅读一个很长的方法并且看到对make_thingumbob（）的调用时，这很困难。 - 你在哪里看
看看它有什么作用？它可能是

类的另一种方法，或者它可能是全局（甚至是内置）函数。然后

需要额外的思考和搜索时间来弄清楚意图。


Python的一个设计原则是*阅读的简易性*是更多

比*写作*的重要性更重要。如果

它可以为您节省一两秒的时间来阅读不熟悉的代码 -

，因为大多数代码只写一次，但是阅读*很多次*


Jeff Shannon

技术员/程序员

Credit International

>>>>> "杰夫" == Jeff Shannon< je ** @ ccvcorp.com>写道：


杰夫>但是等待 - open（）是一个过时的内置函数，用于

Jeff>打开一个文件。哪个应该eye.blink（）做 - 打开和

杰夫>闭上右眼，或者


我只想指出open（）绝不会过时，即使

它'' s别名为file。它可能只占现有代码中5％的内置内容的价值，因此弃用它会弃用几乎所有现有python代码的b $ b。 />

我？我确定吗？¤会看到打印在打开之前被弃用。


-

Ville Vainio http://tinyurl.com/2prnb

Ville Vainio写道：

>>"Jeff" == Jeff Shannon< je ** @ ccvcorp.com>写道：
>>
>>

Jeff>但是等等 - open（）是一个过时的内置函数，用于
Jeff>打开一个文件。哪个应该eye.blink（）做 - 打开和
杰夫>关闭右眼，或者

我只想指出open（）绝不会过时，即使
它被别名为file。在现有代码的频率方面，它可能只占内置量的5％，所以弃用它几乎都会弃用所有现有的python代码。

我？ 我确定吗？看到打印在打开之前被弃用。

好​​吧，也许是遗产是一个比过时更好的术语。在

的情况下，建议不要在新代码中使用它，即使有

目前没有计划将其删除。并不是说这个案例的细节是

特别与我的观点密切相关......


Jeff Shannon

技术员/程序员

Credit International

Using ''self'' in classes seems pretty straight forward. My curiosity is
why I have to use it. Shouldn''t it be implied? If I create an instance
of ''human'' called ''bruce'' and call the method ''blink'' why do I have to
pass bruce into the method e.g.

class human:
...code
def blink(self,times):
for i in range(times):
if self.eye_is_closed:
self.eye_open()
self.eye_close()
else:
self.eye_close()
self.eye_open()
def eye_open(self):
...code
def eye_close(self):
...code
bruce = human()
bruce.blink(5)

blink is a method of bruce because bruce is an instance of human.
Reading this silly code I can understand what is going on if self was
not included. Can anyone enlighten me as to why we have self?

by the way..six months of python and I''m 10 times the programmer I was
with vb
v/r
Bruce

解决方案

bruce stockwell wrote:

Using ''self'' in classes seems pretty straight forward. My curiosity is
why I have to use it. Shouldn''t it be implied?

The problem is that an implied ''self'' is harder to read than an explicit
''self'', and also opens the door for ambiguity when an instance attribute
has the same name as a global or builtin attribute.

Let''s look at an example in a hypothetical Python variant where ''self''
is implied --

class eye:
def open(which):
# do stuff here

def close(which):
# do stuff here

def blink(which):
if closed:
open(which)
close(which)
else:
close(which)
open(which)

e = eye()
e.blink(''right'')

But wait -- open() is an obsolete built-in function for opening a file.
Which should eye.blink() do -- open and close the right eye, or open a
file with the name of ''right'' ?? If it''s the former, then what do you
do if you *want* to open that file? If it''s the latter, then what
happens when the next version of Python comes along and open() has been
removed from built-ins?

Even without these namespace conflicts, it''s difficult when you''re
reading a long method and see a call to "make_thingumbob()" -- where do
you look to see what that does? It might be another method of that
class, or it might be a global (or even built-in) function. It then
requires extra thought and search-time to figure out the intent.

One of the design principles of Python is that ease of *reading* is more
important than ease of *writing*. It''s worth a few extra keystrokes if
it will save you a second or two of time when reading unfamiliar code --
because most code is only written once, but read *many* times.

Jeff Shannon
Technician/Programmer
Credit International

>>>>> "Jeff" == Jeff Shannon <je**@ccvcorp.com> writes:

Jeff> But wait -- open() is an obsolete built-in function for
Jeff> opening a file. Which should eye.blink() do -- open and
Jeff> close the right eye, or

I''ll just like to point out that open() is in no way obsolete, even if
it''s aliased to "file". It?''s probably intop 5% of builtins in terms
of frequency in existing code, so deprecating it would deprecate
pretty much all the existing python code.

I?''m sure ?¤ll see "print" being deprecated before "open".

--
Ville Vainio http://tinyurl.com/2prnb

Ville Vainio wrote:

>>"Jeff" == Jeff Shannon <je**@ccvcorp.com> writes:
>>
>>

Jeff> But wait -- open() is an obsolete built-in function for
Jeff> opening a file. Which should eye.blink() do -- open and
Jeff> close the right eye, or

I''ll just like to point out that open() is in no way obsolete, even if
it''s aliased to "file". It?''s probably intop 5% of builtins in terms
of frequency in existing code, so deprecating it would deprecate
pretty much all the existing python code.

I?''m sure ?¤ll see "print" being deprecated before "open".

Okay, perhaps "legacy" is a better term than "obsolete". In either
case, it''s recommended that it not be used in new code, even if there is
no current plan to remove it. Not that the specifics of this case are
particularly germane to the point I was making...

Jeff Shannon
Technician/Programmer
Credit International

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