另一种尝试Python的自私 [英] Another try at Python's selfishness

问题描述

在阅读过之前关于python-dev的讨论后，我想我不是唯一一个并不特别喜欢python的自我的Python程序员。

参数：


class Foo：

def bar（self，a，b）：

返回a + b

Foo（）。bar（1,2）=> 3


主要原因（至少对我而言）是因为太多了b $ b魔术在里面。为什么''。''左边的表达式被提升为

第一个参数？它甚至更进一步：


Foo.bar（Foo（），1,2）


有效，但是：
< br $>
Foo.bar（1,2,3）

并不是因为神奇的第一个参数而已。在会员

功能。但是：


Foo .__ dict [" bar"] __（1,2,3）


工作。


重点是，我认为明确地写一个好主意

" self.SomeMember"对于成员访问，所以我想：为什么我们不能

同样明确关于成员函数声明？如果我能写（比如说，在Python 3k中，或者稍后），那不是很好吗

：


class Foo：

def self.bar（a，b）：

返回a + b

Foo（）。bar（1,2）=> 3


这样，声明将与调用相匹配（至少语法上为
），并且魔法感觉消失了。从长远来看，

" old-style"语法（即如果方法名称中没有''。''可能是

用于静态方法。


你怎么看？ ？

Having read previous discussions on python-dev I think I''m not the only
Python programmer who doesn''t particularly like python''s "self"
parameter:

class Foo:
def bar(self, a,b):
return a+b
Foo().bar(1,2) => 3

The main reason (at least for me) is that there''s simply too much
"magic" in it. Why does the expression left of the ''.'' get promoted to
the first parameter? It even goes further:

Foo.bar(Foo(), 1,2)

works, but:

Foo.bar(1,2,3)

doesn''t, just because of the "magical first parameter" in a member
function. But:

Foo.__dict["bar"]__(1,2,3)

Does work.

The point is, I _do_ think it''s a good idea to explicitly write
"self.SomeMember" for member-access, so I thought: why can''t we be
equally explicit about member function declaration? Wouldn''t it be nice
if I could write (say, in Python 3k, or maybe later):

class Foo:
def self.bar(a,b):
return a+b
Foo().bar(1,2) => 3

That way, the declaration would match the invocation (at least
syntactically), and the "magic"-feeling is gone. In the long run, the
"old-style" syntax (i.e. if there''s no ''.'' in the method name) could be
used for static methods.

What do you think?

推荐答案

文章< 11 ******************* ***@o13g2000cwo.googlegroups .com> ;,
n。****** @ gmx.de 写道：

In article <11**********************@o13g2000cwo.googlegroups .com>,
n.******@gmx.de wrote:

读过以前关于python-dev的讨论我觉得我不是唯一一个不特别喜欢python'的Python程序员自我
参数：

类Foo：
def bar（self，a，b）：
返回a + b
Foo（） .bar（1,2）=> 3

主要原因（至少对我而言）是魔法太多了。在里面。为什么''。''左边的表达式被提升为第一个参数？它甚至更进一步：

Foo.bar（Foo（），1,2）

有效，但是：

Foo.bar（1 ，2,3）

不仅仅是因为神奇的第一个参数。在会员
功能。但是：

Foo .__ dict [" bar"] __（1,2,3）

是否有效。

重点是，我认为明确写出self.SomeMember是一个好主意。对于成员访问，所以我想：为什么我们不能同样明确关于成员函数声明？如果我能写（比如说，在Python 3k中，或者稍后），那不是很好吗：

类Foo：
def self.bar（a，b ）：
返回a + b
Foo（）。bar（1,2）=> 3

这样，声明将匹配调用（至少在语法上），并且魔法感觉消失了。从长远来看，
旧式语法（即如果方法名称中没有''。''可以用于静态方法。

你怎么看？

Having read previous discussions on python-dev I think I''m not the only
Python programmer who doesn''t particularly like python''s "self"
parameter:

class Foo:
def bar(self, a,b):
return a+b
Foo().bar(1,2) => 3

The main reason (at least for me) is that there''s simply too much
"magic" in it. Why does the expression left of the ''.'' get promoted to
the first parameter? It even goes further:

Foo.bar(Foo(), 1,2)

works, but:

Foo.bar(1,2,3)

doesn''t, just because of the "magical first parameter" in a member
function. But:

Foo.__dict["bar"]__(1,2,3)

Does work.

The point is, I _do_ think it''s a good idea to explicitly write
"self.SomeMember" for member-access, so I thought: why can''t we be
equally explicit about member function declaration? Wouldn''t it be nice
if I could write (say, in Python 3k, or maybe later):

class Foo:
def self.bar(a,b):
return a+b
Foo().bar(1,2) => 3

That way, the declaration would match the invocation (at least
syntactically), and the "magic"-feeling is gone. In the long run, the
"old-style" syntax (i.e. if there''s no ''.'' in the method name) could be
used for static methods.

What do you think?

我觉得你太复杂了。为什么不能以同样的方式声明和调用
函数，

对每个人来说都是最简单的事情。


class Foo

def bar（self，a，b）：

返回+ b

bar（Foo（），1 ，2）=> 3

这种一致性的优点在更复杂的功能背景下变得更加明显：


sys。 stdin.write（open（file，''r''）。read（）。split（sep）[0]）


vs.

写（sys.stdin，split（read（open（file，''r''）））[0]）


Donn Cave，做** @ u.washington.edu

< n。****** @ gmx.de> ;在消息中写道

news：11 ********************** @ o13g2000cwo.googlegr oups.com ...

<n.******@gmx.de> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

阅读过之前关于python-dev的讨论我认为我不是唯一一个并不特别喜欢python'的'self"
参数的Python程序员：

Having read previous discussions on python-dev I think I''m not the only
Python programmer who doesn''t particularly like python''s "self"
parameter:

这个基于装饰器的方法怎么样（仍需要为

self选择* some * name，我选择了__）。


- 保罗


def memberFunction（f）：

def func（self，* args，** kwargs）：

globals（）[" __"] = self

返回f（* args，** kwargs）

func。 __name__ = f .__ name__

func .__ doc__ = f .__ doc__

func .__ dict __。update（f .__ dict__）

return func

类测试：

@memberFunction

def __init __（x，y）：

__。x = x

__。y = y


@memberFunction

def mult（）：

"乘以两个米ember vars"

返回__。x * __。y

t =测试（5,4）

print t.mult（）

print dir（t）

print t.mult .__ doc__

How about this decorator-based approach (still need to pick *some* name for
self, I picked "__").

-- Paul

def memberFunction(f):
def func(self,*args,**kwargs):
globals()["__"] = self
return f(*args,**kwargs)
func.__name__ = f.__name__
func.__doc__ = f.__doc__
func.__dict__.update(f.__dict__)
return func
class Test:
@memberFunction
def __init__(x,y):
__.x = x
__.y = y

@memberFunction
def mult():
"Multiply the two member vars"
return __.x * __.y
t = Test(5,4)
print t.mult()
print dir(t)
print t.mult.__doc__

>写（sys.stdin，split（读取（打开（文件，''r''）））[0]）


所以，如果我说得对，解释器会有解释这个

这样的行：

1.评估第一个函数的第一个参数（sys.stdin）

2.查找属性写在这个对象中

3.评估分割函数的第一个参数 - >

4.评估读取函数的第一个参数 - >

5.评估文件（我猜这是一个本地字符串变量？）
6.尝试属性查找打开在字符串上

7.失败 - >称全球开放功能

8.查找阅读在该对象中，将其称为

9.属性查找" split"在返回的对象上

10.调用__getitem __（0）

11.将参数传递给写入函数（1）


这是正确的吗？

我的主要问题是你必须猜测在步骤6/7，并且

的评价顺序让我有点头晕;-)另外，成员函数

似乎是影子全球性的，如果我想使用一些全球性的话，那么该怎么办？我写的是自己而不是字符串的一个。如果我是
是卑鄙的，我会问你这个人做了什么：

A级：

def测试（自我，这个） ：返回1

B级：

def测试（这个，自我）：返回2

测试（自我= A（），这= B（））


当前的调用语法至少可以从左到右读取，

你总是知道你是否调用成员函数或全球性的。

> write(sys.stdin, split(read(open(file, ''r'')))[0])

So, if I got you right, the interpreter would have to interpret this
line like this:
1. Evaluate the first parameter of the first function (sys.stdin)
2. Look up the attribute "write" in this object
3. evaluate the first parameter of the split function ->
4. evaluate the first parameter of the read function ->
5. evaluate file (I guess this is a local string variable?)
6. try attribute lookup "open" on the string
7. fail -> call the global "open" function
8. lookup "read" in that object, call it
9. attribute lookup "split" on the returned object
10. call __getitem__(0)
11. pass the parameters to the write function from (1)

Is this correct?
My main problems are that you have to "guess" at step 6/7, and that the
order of evaluation makes me a little dizzy ;-) Also, member functions
seem to "shadow" global ones, what if I wanted to use some global
"split" function I''ve written myself instead of the string''s one. If I
was mean, I''d ask you what this one does:
class A:
def test(self, this): return 1
class B:
def test(this, self): return 2
test(self=A(), this=B())

The current call syntax at least can be read from left-to-right, and
you always know whether you call a member function or a global one.

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