PEP 318：难道我们都不能相处吗？ [英] PEP 318: Can't we all just get along?

问题描述

为了它的价值，我写了原始的PEP 318.我可能不是
合格，但我只是想要一个简单的方法来声明类方法

，无需重复功能名称。在将其提交给BDFL

进行审批后，需要做更多的工作，并且对于

python-dev的PEP 318的讨论迅速增加。很明显，我在我的头上，

所以我要求更多有经验的人来接管。


我猜其他人对我有更大的计划我计划的提案。它已经变成了解决方案。许多问题：类型检查（

参数和返回值），元类，元数据，接口，
函数属性等）。不幸的是，在这个过程中，这个简单的语法糖请求变成了怪异。在我的

意见中，所提出的语法都没有真正看起来像Pythonic。这个PEP

似乎试图解决太多问题。


跟我一起，但我想提出一个更多的语法简单，

易于新手理解，并且远不如当前PEP的语法那么强大。但是，它也没有添加语无关，任意的

语法。


def classmethod foo（x，y，z）：

通过


就是这样。一个装饰器这是一个可调用的对象，它采用

方法，因为它是唯一的参数。没有表达式，列表，元组等等。只需

一个可调用对象。好的，如果你绝对必须有多个。


def classmethod synchronized foo（x，y，z）：

pass


再次，没有表达式。我知道这不会解决

每个人的类型检查，元数据和函数属性问题，但是

让我们面对它，将这个PEP用于所有这些事情只会产生丑陋的

语法。必须有更多Pythonic方式在他们的自己的PEP中做这些事情。


-

Kevin Smith Ke*********@sas.com

For what it''s worth, I wrote the original PEP 318. I probably wasn''t
qualified, but I just wanted a nice simple way to declare class methods
without having to repeat the function name. After submitting it to BDFL
for approval, more work was needed and the discussion of PEP 318 on
python-dev increased rapidly. It was evident that I was in over my head,
so I asked more someone more experienced to take over.

I guess others had bigger plans for my proposal that I had planned. It
has turned into the "solution" to many problems: type checking (both
arguments and returned values), metaclasses, metadata, interfaces,
function attributes, etc.). Unfortunately, in the process, this simple
request for syntactical sugar has turned into a monstrosity. In my
opinion, none of the proposed syntaxes really seem Pythonic. This PEP
just seems to be trying to solve too many problems.

Bear with me, but I''d like to propose one more syntax that is simple,
easy for newbies to understand, and nowhere near as powerful as the
current PEP''s syntax. However, it doesn''t add incoherent, arbitrary
syntax either.

def classmethod foo(x, y, z):
pass

That''s it. One "decorator" that is a callable object that takes a
method as it''s only argument. No expressions, lists, tuples, etc. Just
one callable object. Ok, if you absolutely must have more than one.

def classmethod synchronized foo(x, y, z):
pass

Once again, no expressions. I know that this isn''t going to solve
everyone''s type-checking, metadata, and function attribute problems, but
let''s face it, using this PEP for all of those things just creates ugly
syntax. There must be more Pythonic ways to do those things in their
own PEPs.

--
Kevin Smith
Ke*********@sas.com

推荐答案

Kevin Smith写道：

Kevin Smith wrote:

为了它的价值，我写了原始的PEP 318.我可能不是
合格，但我只想要一个简单的方法来声明类方法
而不必重复函数名称。在将其提交给BDFL进行审批之后，需要做更多的工作，并且关于
python-dev的PEP 318的讨论迅速增加。很明显，我在我的脑海里，所以我要求更多有经验的人接手。

我猜其他人对我的计划有更大的计划。它已经变成了解决方案。许多问题：类型检查（
参数和返回值），元类，元数据，接口，
函数属性等）。不幸的是，在这个过程中，这种简单的语法糖请求变成了怪异。在我看来，所提出的语法都不是真正的Pythonic。这个PEP似乎试图解决太多问题。

请耐心等待，但我想提出一个简单的语法，
新手要理解，并且远不如当前PEP的语法那么强大。但是，它也没有添加语无关，任意的语法。

def classmethod foo（x，y，z）：
传递

而已。一个装饰器这是一个可调用的对象，它采用
方法作为唯一的参数。没有表达式，列表，元组等等。只是一个可调用的对象。好吧，如果你绝对必须有多个。

def classmethod synchronized foo（x，y，z）：
传递

再次，没有表达式。我知道这不会解决每个人的类型检查，元数据和函数属性问题，但是让我们面对它，使用这个PEP来处理所有这些事情只是创造了丑陋的语法。必须有更多的Pythonic方法在他们自己的PEP中做这些事情。

For what it''s worth, I wrote the original PEP 318. I probably wasn''t
qualified, but I just wanted a nice simple way to declare class methods
without having to repeat the function name. After submitting it to BDFL
for approval, more work was needed and the discussion of PEP 318 on
python-dev increased rapidly. It was evident that I was in over my head,
so I asked more someone more experienced to take over.

I guess others had bigger plans for my proposal that I had planned. It
has turned into the "solution" to many problems: type checking (both
arguments and returned values), metaclasses, metadata, interfaces,
function attributes, etc.). Unfortunately, in the process, this simple
request for syntactical sugar has turned into a monstrosity. In my
opinion, none of the proposed syntaxes really seem Pythonic. This PEP
just seems to be trying to solve too many problems.

Bear with me, but I''d like to propose one more syntax that is simple,
easy for newbies to understand, and nowhere near as powerful as the
current PEP''s syntax. However, it doesn''t add incoherent, arbitrary
syntax either.

def classmethod foo(x, y, z):
pass

That''s it. One "decorator" that is a callable object that takes a
method as it''s only argument. No expressions, lists, tuples, etc. Just
one callable object. Ok, if you absolutely must have more than one.

def classmethod synchronized foo(x, y, z):
pass

Once again, no expressions. I know that this isn''t going to solve
everyone''s type-checking, metadata, and function attribute problems, but
let''s face it, using this PEP for all of those things just creates ugly
syntax. There must be more Pythonic ways to do those things in their
own PEPs.

Nope。那是'使用静态声明。我们尽可能使用动态类型的

语言。难道没有什么东西不需要额外的语法词来识别类方法和

staticmethods吗？静态，

类以及实例方法看起来自然地存在固有的东西，它会告诉我们它们是什么？b $ b？ br />

Nope. That''s using static declarations. We''re a dynamically typed
language as much as possible. Isn''t there something that doesn''t
require any additional grammar words to identify classmethods and
staticmethods? Isn''t there something, inherent in the way static,
class, and instance methods ''look'' naturally, that would tell us what
they are?

Paul Morrow写道：

Paul Morrow wrote:

Kevin Smith写道：

Kevin Smith wrote:

def classmethod foo（ x，y，z）：
传递

就是这样。一个装饰器这是一个可调用的对象，它采用
方法作为唯一的参数。没有表达式，列表，元组等。
只有一个可调用的对象。

def classmethod foo(x, y, z):
pass

That''s it. One "decorator" that is a callable object that takes a
method as it''s only argument. No expressions, lists, tuples, etc.
Just one callable object.

不。那是'使用静态声明。我们尽可能使用动态类型语言。是不是有什么东西不需要任何额外的语法词来识别类方法和
staticmethods？

Nope. That''s using static declarations. We''re a dynamically typed
language as much as possible. Isn''t there something that doesn''t
require any additional grammar words to identify classmethods and
staticmethods?

它看起来对我来说好像凯文不建议使用关键字，但

callables。换句话说，他认为这是有效的，只要

my_own_decorator是可以调用的。


def my_own_decorator foo（x，y，z）：

通过

-Peter

It looks to me as though Kevin is not suggesting keywords, but
callables. In other words he would consider this valid, provided
my_own_decorator was a callable.

def my_own_decorator foo(x, y, z):
pass
-Peter

Peter Hansen写道：

Peter Hansen wrote:

Paul Morrow写道：

Paul Morrow wrote:

Kevin Smith写道：

Kevin Smith wrote:

def classmethod foo（x，y，z）：
传递
方法作为唯一的参数。没有表达式，列表，元组等。
只有一个可调用对象。

def classmethod foo(x, y, z):
pass

That''s it. One "decorator" that is a callable object that takes a
method as it''s only argument. No expressions, lists, tuples, etc.
Just one callable object.

Nope。那是'使用静态声明。我们尽可能使用动态类型语言。是不是有什么东西不需要任何额外的语法词来识别类方法和
staticmethods？

Nope. That''s using static declarations. We''re a dynamically typed
language as much as possible. Isn''t there something that doesn''t
require any additional grammar words to identify classmethods and
staticmethods?

它看起来好像凯文是不建议关键字，但
callables。换句话说，如果my_own_decorator是可调用的，他会认为这是有效的。

def my_own_decorator foo（x，y，z）：
传递

-Peter

It looks to me as though Kevin is not suggesting keywords, but
callables. In other words he would consider this valid, provided
my_own_decorator was a callable.

def my_own_decorator foo(x, y, z):
pass
-Peter

哦，对不起，我没有那么仔细地阅读。嗯......这是一个有趣的想法。它并不难看......


首先，我仍然相信我们应该利用现有的

约定（推荐的编码实践）作为一种方式获得''free''

类，静态和实例方法的声明（例如，
第一个参数是'self''的方法是实例方法等） 。对我来说，感觉非常好，就像我们使用命名约定区分公共，

私有和半私有方法一样。


但我认为，我们想要提供有关

方法的其他信息，并且没有可以利用的惯例，Kevin的

建议确实有一些吸引力。


问题（对凯文来说）：


1.会是


def deco1 foo（a，b，c）：传递


与（只是语法糖）相同


def foo（a ，b，c）：传递

foo = deco1（foo）


或者它意味着什么？


2.


def deco1 deco2 foo（a，b，c）：传递


与
相同

def foo（a，b，c）：传递

foo = deco1（deco2（foo））


或


def foo（a，b，c）：传递

foo = deco2（deco1（foo））

3.会不会什么装饰有任何限制rator可以*兑换它通过的

方法吗？例如它可以改变：


*方法的名称（当然可以影响方法的

可见性：public | private | semi-私有）？

*方法是静态的，类还是实例方法？

*方法的签名（形式参数名称，参数顺序，

默认值）？

Oh, sorry, I wasn''t reading that closely enough. Hmmmm... it''s an
interesting idea. It''s not ugly...

First though, I still believe that we should exploit existing
conventions (recommended coding practices) as a way of getting ''free''
declarations for class, static, and instance methods (e.g. methods whose
first param is ''self'' are instance methods, etc.). That feels very
pythonic to me, just as we use naming conventions to distinguish public,
private, and semi-private methods.

But I think that, where we want to provide additional info about a
method, and there are no conventions to take advantage of, Kevin''s
suggestion does have some appeal.

Questions (for Kevin):

1. Would

def deco1 foo(a, b, c): pass

be the same as (just syntactic sugar for)

def foo(a, b, c): pass
foo = deco1(foo)

or would it mean something else?

2. Would

def deco1 deco2 foo(a, b, c): pass

be the same as

def foo(a, b, c): pass
foo = deco1(deco2(foo))

or

def foo(a, b, c): pass
foo = deco2(deco1(foo))
3. Would there be any restrictions on what a decorator could *do* to the
method it was passed? e.g. Could it change:

* the method''s name (which could of course affect the method''s
visibility: public|private|semi-private)?
* whether the method was a static, class, or instance method?
* the method''s signature (formal parameter names, parameter order,
defaults values)?

这篇关于PEP 318：难道我们都不能相处吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！