方法和功能的统一 [英] Unification of Methods and Functions

问题描述

我没有得到任何有关我提出的b3想法的最重要的好处的反馈意见。线程 - 方法的统一和

函数。也许它被埋没在太多其他不太重要的变化之中，所以在这个帖子中我想单独关注这个问题。


我编辑了下面提出的语法示例可以取消

对此讨论不必要的更改。我改变了

" instance variable"语法（self.sound - > .sound）因为这是统一所有方法表单所必需的
。 （比较下面''show''和''talk''方法的

形式。）


我相信语法的这些变化会使教学变得更好Python中的OOP

更容易。参见Prototypes.doc和Prototypes.doc。在
http://ece.arizona.edu/~edatools/ Python / 前八页是基本的，但是完整呈现了新的OOP语法。我希望这个

扩展到大约30页，有更多的例子和练习。这个

与Learning Python 2nd ed中的大约60页相比。


如果我们根据教科书所需的页数来衡量复杂性>
解释" OOP，那么我相信新的语法有一些真正的好处
的好处。在学习过程中，学生已经知道了b $ b函数，模块和全局变量。使用

全局变量__self__的概念根本不足为奇。与模块相比，

类中唯一新增的是实例变量，它们可以在一个段落中解释为
。所有方法看起来都像普通的

函数。没有必要解释静态方法。或任何其他

形式的方法。事实上，我使用术语功能。而不是

" method"强调相似性。


我特别感兴趣的是那些正在学习

或最近学过Python的用户的反馈。我已经知道这些变化似乎对很多专家来说都是微不足道的。我也听过很多人说过很多人认为Python太复杂了我们需要开始一种全新的语言

（ www.prothon.org ）。我正在寻找中间立场。我相信

可以采用Prothon的优点，而不是失去10年b / b
的软件和社区开发。


=======语法示例=============

##提议语法：

class猫（猫）：

numCats = 0

def __init __（n =" unknown"，s =" Meow"）：

Feline .__ init __（）

Cat.numCats + = 1

.name = n＃设置实例变量。

.sound = s

def show（）：#define astatic method。

Feline.show（）

print" Cats："，Cat.numCats

def talk（）：

print"我的名字是..." .name

打印我是来自％s的％s ％（。genus，.home）

Mammal.talk（）＃调用未绑定的函数。

print __self__ ###诊断检查。

cat1 = Cat（）＃创建实例。

bf = cat1.talk＃制作绑定函数。

##等效Python：

class Cat（猫）：

numCats = 0

def __init __（self，n =" unknown"，s =" Meow"）：

Feline .__ init __（self）

Cat.numCats + = 1

self.name = n

self。声音= s

def show（）：

Feline.show（）

print" Cats："，Cat.numCats

show = staticmethod（show）

def talk（self）：

print"我的名字是..."，self.name

print"我是来自％s的％s" ％（self.genus，self.home）

Mammal.talk（个体经营）

打印自我

cat1 = Cat（ ）＃创建实例。

bf = cat1.talk＃制作绑定函数。


=========示例结束== =====


感谢您的帮助。


- Dave

I''m not getting any feedback on the most important benefit in my
proposed "Ideas for Python 3" thread - the unification of methods and
functions. Perhaps it was buried among too many other less important
changes, so in this thread I would like to focus on that issue alone.

I have edited the Proposed Syntax example below to take out the
changes unecessary to this discussion. I left in the change of
"instance variable" syntax ( self.sound --> .sound ) because that is
necessary for the unification of all method forms. ( Compare the
forms of the ''show'' and ''talk'' methods below.)

I believe these changes in syntax will make teaching OOP in Python
much easier. See "Prototypes.doc" at
http://ece.arizona.edu/~edatools/Python/ The first eight pages are a
basic, but complete presentation of the new OOP syntax. I expect this
to expand to about 30 pages with more examples and exercises. This
compares to about 60 pages in Learning Python 2nd ed.

If we measure complexity by the number of pages needed for a "textbook
explanation" of OOP, then I believe the new syntax has some real
benefits. At this point in the learning process, students already know
functions, modules, and global variables. The concept of using a
global variable __self__ is no surprise at all. The only thing new in
a class, compared to a module, is the instance variables, and they can
be explained in one paragraph. All methods look just like normal
functions. There is no need to explain "static methods" or any other
form of method. In fact, I use the term "function" rather than
"method" to emphasize the similarity.

I''m especially interested in feedback from users who are now learning
or have recently learned Python. I already know these changes seem
trivial to many experts. I''ve also heard plenty from the people who
think Python is so complex that we need to start a whole new language
( www.prothon.org ). I''m looking for a middle ground. I believe it
is possible to adopt what is good about Prothon, and not lose ten
years of software and community development.

======= Syntax Examples =============

## Proposed Syntax:
class Cat(Feline):
numCats = 0
def __init__( n = "unknown", s = "Meow" ):
Feline.__init__()
Cat.numCats += 1
.name = n # Set instance variables.
.sound = s
def show(): # Define a "static method".
Feline.show()
print " Cats:", Cat.numCats
def talk():
print "My name is ...", .name
print "I am a %s from %s" % (.genus, .home)
Mammal.talk() # Call an unbound function.
print __self__ ### Diagnostic check.

cat1 = Cat() # Create instance.
bf = cat1.talk # Make a bound function.
## Equivalent Python:
class Cat(Feline):
numCats = 0
def __init__(self, n = "unknown", s = "Meow" ):
Feline.__init__(self)
Cat.numCats += 1
self.name = n
self.sound = s
def show():
Feline.show()
print " Cats:", Cat.numCats
show = staticmethod(show)
def talk(self):
print "My name is ...", self.name
print "I am a %s from %s" % (self.genus, self.home)
Mammal.talk(self)
print self

cat1 = Cat() # Create instance.
bf = cat1.talk # Make a bound function.

========= End of Examples =======

Thanks for your help.

-- Dave

推荐答案

David MacQuigg写道：

David MacQuigg wrote:

[...]

请原谅我的无知，但我是不太确定这个证书方法怎么样？b $ b和功能。

在我看来，统一将从类中删除方法定义

范围或使它成为简单的语法糖：

def my_method（SomeClass self）：

...


（而不是：

class SomeClass：

def my_method（self）：

...）


这也增加了通过

s提供多次发送的可能性意味着允许类型提示每个位置的每个参数。


干杯，

Michael

Pardon my ignorance, but I''m not quite sure how this unificates methods
and functions at all.

In my eyes, unification would remove method definitions from the "class"
scope or make it simply syntactic sugar for:

def my_method(SomeClass self):
...

(instead of:
class SomeClass:
def my_method(self):
...)

This would also add the possibility to provide multiple dispatch by
simply allowing a "type hint" for every parameter at every position.

Cheers,
Michael

4月30日星期五，2004年上午09:47:05 -0700，David MacQuigg写道：

On Fri, Apr 30, 2004 at 09:47:05AM -0700, David MacQuigg wrote:

我没有得到任何关于我的
提议的Thinking for Python 3中最重要的好处的反馈。线程 - 方法和
功能的统一。也许它被埋没在太多其他不太重要的变化之中，所以在这个帖子中我想单独关注这个问题。
=======语法示例======= ======

##建议语法：
class Cat（Feline）：
numCats = 0
def __init __（n =" unknown"， s =" Meow"）：
Feline .__ init __（）
Cat.numCats + = 1
.name = n＃设置实例变量。
.sound = s
def show（）：#define静态方法。
Feline.show（）
print" Cats："，Cat.numCats
def talk（）：
print"我的名字是..." .name
print"我是来自％s的％s" ; ％（。genus，.home）
Mammal.talk（）＃调用未绑定的函数。
打印__self__ ###诊断检查。

cat1 = Cat（）#Create实例。
bf = cat1.talk＃制作绑定函数。

##等效Python：
类Cat（猫）：
numCats = 0 def __init __（self，n =" unknown"，s =" Meow"）：
Feline .__ init __（self）
Cat.numCats + = 1
self.name = n
self.sound = s
def show（）：
Feline.show（）
print" Cats："，Cat.numCats
show = staticmethod（show）
def talk（self）：
print" my name is ..."，self.name
print我是来自％s的％s ％（self.genus，self.home）
Mammal.talk（self）
print self

cat1 = Cat（）＃创建实例。
bf = cat1 .talk＃制作绑定功能。

=========示例结束=======

I''m not getting any feedback on the most important benefit in my
proposed "Ideas for Python 3" thread - the unification of methods and
functions. Perhaps it was buried among too many other less important
changes, so in this thread I would like to focus on that issue alone.
======= Syntax Examples =============

## Proposed Syntax:
class Cat(Feline):
numCats = 0
def __init__( n = "unknown", s = "Meow" ):
Feline.__init__()
Cat.numCats += 1
.name = n # Set instance variables.
.sound = s
def show(): # Define a "static method".
Feline.show()
print " Cats:", Cat.numCats
def talk():
print "My name is ...", .name
print "I am a %s from %s" % (.genus, .home)
Mammal.talk() # Call an unbound function.
print __self__ ### Diagnostic check.

cat1 = Cat() # Create instance.
bf = cat1.talk # Make a bound function.
## Equivalent Python:
class Cat(Feline):
numCats = 0
def __init__(self, n = "unknown", s = "Meow" ):
Feline.__init__(self)
Cat.numCats += 1
self.name = n
self.sound = s
def show():
Feline.show()
print " Cats:", Cat.numCats
show = staticmethod(show)
def talk(self):
print "My name is ...", self.name
print "I am a %s from %s" % (self.genus, self.home)
Mammal.talk(self)
print self

cat1 = Cat() # Create instance.
bf = cat1.talk # Make a bound function.

========= End of Examples =======

明确胜过隐含。

或

魔法BAAAAAAAAD [菲尔哈特曼饰演弗兰肯斯坦]


我建议你查看perl在实践中看到混合实例/类/静态方法

。因为perl中的''有道理'，所以becuase perl是弱类型的，即使这会导致问题[1]。在实践中发生的事情很糟糕，人们写的功能可以用两种或更多种方式来实现。这使得类型检查很难，并且

使代码不可读。当

以这种或那种方式调用时，函数经常会略有不同。

对于python版本，你可以通过执行

静态分析代码，但那将是unpythonic。我喜欢它当

当一些雅虎尝试使用自己时，静态功能会严重破坏 - 它会早期和大声地打破

。你的方式可能只会破坏某个代码路径，即
尝试访问''.name''并将方法从静态变为实例。

如果你重新添加staticmethod / classmethod用于清除区别然后

上面的例子只是隐含的''self''的新语法。


'的一个版本' '：vars：expression''lambda replacement每隔一段时间就会被建议一次（这个确切的语法就是我）。它不会幸福，拉姆达

更有可能被丢弃而不是增强。


-jackdied


[1]标准perl面试问题，这些

电话有什么区别？所有这些最终都会用一个参数调用meow（），但它们都表现不同 - 有时非常微妙。

Explicit is better than implicit.
or
Magic BAAAAAAAAD [Phil Hartman as Frankenstein]

I suggest you check out perl to see mixing instance/class/static methods
in practice. Becuase perl is weakly typed this ''makes sense'' in perl, even if
it causes problems[1]. What happens in practice is bad, people write functions
that can be used in two or more ways. This makes type checking hard, and
makes code unreadable. Functions frequently do slightly different things when
called one way or another.

For a python version you could do type checking on the function by doing
static analysis of the code, but that would be unpythonic. I like it when
a static function breaks badly when some yahoo tries to use self -- it breaks
early and loudly. Your way might only break on a certain code path that
tries to access ''.name'' and turns the method from static to instance.
If you re-added staticmethod/classmethod to clear up the distinction then
the above example just becomes a new syntax for implicit ''self''.

A version of the '':vars: expression'' lambda replacement gets suggested every
so often (and that exact syntax once by me). It ain''t going to happnen, labmda
is more likely to be dropped than enhanced.

-jackdied

[1] standard perl interview question, what is the difference between these
calls? All of these end up calling meow() with one argument, but they all
behave differently - sometimes very subtly.

ob = new Cat;

ob = new Cat;

这篇关于方法和功能的统一的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！