PEP 359：“制造”声明 [英] PEP 359: The "make" Statement

问题描述

好的，我终于有了一个PEP号码。这是

" make"的最新版本。声明PEP。我将很快发布到python-dev。


再次感谢前面的讨论和建议！

PEP：359

标题：制造声明

版本：$修订：45366 $

最后修改日期：$ Date：2006-04-13 07：36：24 -0600（2006年4月13日星期四） $

作者：Steven Bethard< st ************ @ gmail.com>

状态：草稿

类型：标准跟踪

内容类型：text / x-rst

创建时间：2006年4月5日

Python-Version： 2.6

后历史：2006年4月5日，2006年4月6日

摘要

========


这个PEP提出了类声明语法的概括，

``make``语句。建议的语法和语义并行

类定义的语法，所以::


make< callable> <名称> <元组>：

< block>


被翻译成作业::


<名称> =< callable>（"< name>"，< tuple>，< namespace>）

其中``< namespace>``是创建的dict通过执行``< block>``。

PEP基于Michele Simionato在

python-dev列表中的建议[1] _。 />
动机

==========


类语句为Python提供了两个不错的功能：


（1）它们是创建命名空间的标准Python方法。执行类主体中的所有

语句，并将生成的

本地名称绑定作为dict传递给元类。


（2）他们鼓励干（不要重复自己）允许创建的班级

知道它被分配的名称。


因此在一个简单的类声明中，如::


class C（object）：

x = 1

def foo（self ）：

返回''bar''


元类（``type``）被调用类似::


C = type（''C''，（object，），{''x''：1，''foo''：< function foo at ...>}）


类声明只是上述赋值

语句的语法糖，但显然是一种非常有用的语法糖。它
不仅避免重复C`，而且还简化了dict的创建，允许它表示为一系列的

语句。


从历史上看，类型实例（也就是类对象）是唯一有这种语法支持的

对象。但其他种类的物品可以从这种支持中受益。例如，属性

对象有三个函数参数，但由于属性类型

不能传递给命名空间，这些函数虽然只与
$ b相关$ b属性，必须在它之前声明然后作为参数传递给属性调用

，例如::


class C（object）：< br $> b $ b ...

def get_x（个体经营）：

...

def set_x（个体经营）：< br $> b $ b ...

x =属性（get_x，set_x，...）


有一些食谱[2] _试图解决这个

行为，但是使用新的make语句（以及适当的

属性定义），getter和setter函数可以是

在属性的命名空间中定义，如::


class C（object）：

...

make property x：

def get（self）：

...

def set（self）：

...


这种可调用属性的定义可以是简单如下::


def属性（name，args，namespace）：

fget = namespace.get（''get''）

fset = namespace.get（''set''）

fdel = namespace.get（''delete''）

doc = namespace.get （''__doc__''）

返回__builtin __。property（fget，fset，fdel，doc）


当然，属性只是其中之一可能使用

make语句。 make语句在基本上任何名称与命名空间相关联的情况下都很有用。因此，对于

示例，名称空间可以简单地创建为::


make namespace ns：

"" 这会创建一个名为ns的命名空间，其中包含一个badger属性

和一个垃圾邮件功能"


badger = 42


def spam（）：

...

如果Python获取接口，给定一个适当定义的

``interface``可调，make语句可以支持接口

通过语法创建::


make interface C（...）：

...


这意味着像Zope这样的界面系统不会花费更长时间来滥用类语法创建合适的界面

实例。

规格

=============


Python将翻译一个make语句::


make< callable> <名称> < tuple>：

< block>


进入作业::


< name> =< callable>（"< name>"，< tuple>，< namespace>）

其中``< namespace>``是创建的dict通过执行``< block>``。

``< tuple>``表达式是可选的;如果不存在，将假设一个空元组

。


实现这些语义的补丁可用[3] _。

make语句引入了一个新关键字``make``。因此，在Python

2.6中，必须使用`来自

__future__ import make_statement``启用make语句。

Open Issues < br $>
===========


``make``关键字会破坏太多代码吗？最初，make

语句使用了关键字``create``（由于Nick

Coghlan的建议）。然而，调查标准库[4] _和

Zope + Plone代码[5] _显示``create``会破坏更多

代码，所以``make``被用作关键字。然而，还有一些实例，其中``make``会破坏代码。声明中是否有更好的关键字？


**********


目前，没有很多函数具有签名

``（name，args，kwargs）``。这意味着像::


这样的东西使得dict params：

x = 1

y = 2

目前是不可能的，因为dict构造函数具有不同的

签名。这类事需要得到支持吗？ Carl Banks提出的一个建议是，在``__call__``之前添加一个``__make__``魔术方法

。对于类型，``__make__``

方法与``__call__``相同（因而不必要），但

dicts可以通过定义来支持make语句dict类型的``__make__``

方法看起来像::


def __make __（cls，name，args，kwargs）：

返回cls（** kwargs）


当然，而不是添加另一种魔法，dict类型

可能会增长类似于``dict.fromblock``的类方法，可以使用

像::


make dict.fromblock params：

x = 1

y = 2

可选扩展

================== =


删除make关键字

-------------------------


有可能删除make关键字，以便这样的

语句以调用可调用对象开头，例如::


命名空间ns：

badger = 42

def spam（）：

...


接口C（...）：

...


然而，几乎所有其他Python语句都开始了使用关键字和

删除关键字会使得在文档中查找此构造更加困难。另外，这会增加语法中的一些复杂性，而且到目前为止我（Steven Bethard）还没有能够实现没有关键字的功能。

删除Python 3000中的__metaclass__

--------------------------------- ----


作为其一般性的副作用，make语句主要是

消除了课堂上``__metaclass__``属性的需要

对象。因此在Python 3000中，而不是::


class< name> < bases-tuple>：

__metaclass__ =< metaclass>

< block>


metaclasses可以得到以下支持：在make语句中使用元类作为可调用的

::


make< metaclass> <名称> < bases-tuple>：

< block>


删除``__metaclass__``钩子会简化BUILD_CLASS

操作码。

删除Python 3000中的类语句

----------------------- -----------------


在最极端的make语句应用中，类

语句本身可以弃用make type``

语句。

引用

==========


... [1] Michele Simionato的原始建议

（ http://mail.python.org/pipermail/pyt...er/057435.html ）


... [2]基于命名空间的属性配方

（ http://aspn.activestate.com/ASPN/Coo.../Recipe/442418 ）


... [3] Make Sta补丁补丁

（ http：// ucsu.colorado.edu/~bethard/py...tatement.patch ）


... [4]在stdlib中创建的实例

（ http：// mail。 python.org/pipermail/pyt...il/335159.html ）


... [5]在Zope + Plone中创建的实例

（ http：// mail。 python.org/pipermail/pyt...il/335284.html ）

版权

=========


本文档已被置于公共领域。


...

本地变量：

模式：缩进文本

indent-tabs-mode：nil

句末 - 双 - 空格：t

填充栏：70

编码：utf-8

E nd：

Ok, I finally have a PEP number. Here''s the most updated version of the
"make" statement PEP. I''ll be posting it shortly to python-dev.

Thanks again for the previous discussion and suggestions!
PEP: 359
Title: The "make" Statement
Version: $Revision: 45366 $
Last-Modified: $Date: 2006-04-13 07:36:24 -0600 (Thu, 13 Apr 2006) $
Author: Steven Bethard <st************@gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006, 06-Apr-2006
Abstract
========

This PEP proposes a generalization of the class-declaration syntax,
the ``make`` statement. The proposed syntax and semantics parallel
the syntax for class definition, and so::

make <callable> <name> <tuple>:
<block>

is translated into the assignment::

<name> = <callable>("<name>", <tuple>, <namespace>)

where ``<namespace>`` is the dict created by executing ``<block>``.
The PEP is based on a suggestion [1]_ from Michele Simionato on the
python-dev list.
Motivation
==========

Class statements provide two nice facilities to Python:

(1) They are the standard Python means of creating a namespace. All
statements within a class body are executed, and the resulting
local name bindings are passed as a dict to the metaclass.

(2) They encourage DRY (don''t repeat yourself) by allowing the class
being created to know the name it is being assigned.

Thus in a simple class statement like::

class C(object):
x = 1
def foo(self):
return ''bar''

the metaclass (``type``) gets called with something like::

C = type(''C'', (object,), {''x'':1, ''foo'':<function foo at ...>})

The class statement is just syntactic sugar for the above assignment
statement, but clearly a very useful sort of syntactic sugar. It
avoids not only the repetition of ``C``, but also simplifies the
creation of the dict by allowing it to be expressed as a series of
statements.

Historically, type instances (a.k.a. class objects) have been the only
objects blessed with this sort of syntactic support. But other sorts
of objects could benefit from such support. For example, property
objects take three function arguments, but because the property type
cannot be passed a namespace, these functions, though relevant only to
the property, must be declared before it and then passed as arguments
to the property call, e.g.::

class C(object):
...
def get_x(self):
...
def set_x(self):
...
x = property(get_x, set_x, ...)

There have been a few recipes [2]_ trying to work around this
behavior, but with the new make statement (and an appropriate
definition of property), the getter and setter functions can be
defined in the property''s namespace like::

class C(object):
...
make property x:
def get(self):
...
def set(self):
...

The definition of such a property callable could be as simple as::

def property(name, args, namespace):
fget = namespace.get(''get'')
fset = namespace.get(''set'')
fdel = namespace.get(''delete'')
doc = namespace.get(''__doc__'')
return __builtin__.property(fget, fset, fdel, doc)

Of course, properties are only one of the many possible uses of the
make statement. The make statement is useful in essentially any
situation where a name is associated with a namespace. So, for
example, namespaces could be created as simply as::

make namespace ns:
"""This creates a namespace named ns with a badger attribute
and a spam function"""

badger = 42

def spam():
...

And if Python acquires interfaces, given an appropriately defined
``interface`` callable, the make statement can support interface
creation through the syntax::

make interface C(...):
...

This would mean that interface systems like that of Zope would no
longer have to abuse the class syntax to create proper interface
instances.
Specification
=============

Python will translate a make statement::

make <callable> <name> <tuple>:
<block>

into the assignment::

<name> = <callable>("<name>", <tuple>, <namespace>)

where ``<namespace>`` is the dict created by executing ``<block>``.
The ``<tuple>`` expression is optional; if not present, an empty tuple
will be assumed.

A patch is available implementing these semantics [3]_.

The make statement introduces a new keyword, ``make``. Thus in Python
2.6, the make statement will have to be enabled using ``from
__future__ import make_statement``.
Open Issues
===========

Does the ``make`` keyword break too much code? Originally, the make
statement used the keyword ``create`` (a suggestion due to Nick
Coghlan). However, investigations into the standard library [4]_ and
Zope+Plone code [5]_ revealed that ``create`` would break a lot more
code, so ``make`` was adopted as the keyword instead. However, there
are still a few instances where ``make`` would break code. Is there a
better keyword for the statement?

**********

Currently, there are not many functions which have the signature
``(name, args, kwargs)``. That means that something like::

make dict params:
x = 1
y = 2

is currently impossible because the dict constructor has a different
signature. Does this sort of thing need to be supported? One
suggestion, by Carl Banks, would be to add a ``__make__`` magic method
that would be called before ``__call__``. For types, the ``__make__``
method would be identical to ``__call__`` (and thus unnecessary), but
dicts could support the make statement by defining a ``__make__``
method on the dict type that looks something like::

def __make__(cls, name, args, kwargs):
return cls(**kwargs)

Of course, rather than adding another magic method, the dict type
could just grow a classmethod something like ``dict.fromblock`` that
could be used like::

make dict.fromblock params:
x = 1
y = 2
Optional Extensions
===================

Remove the make keyword
-------------------------

It might be possible to remove the make keyword so that such
statements would begin with the callable being called, e.g.::

namespace ns:
badger = 42
def spam():
...

interface C(...):
...

However, almost all other Python statements begin with a keyword, and
removing the keyword would make it harder to look up this construct in
the documentation. Additionally, this would add some complexity in
the grammar and so far I (Steven Bethard) have not been able to
implement the feature without the keyword.
Removing __metaclass__ in Python 3000
-------------------------------------

As a side-effect of its generality, the make statement mostly
eliminates the need for the ``__metaclass__`` attribute in class
objects. Thus in Python 3000, instead of::

class <name> <bases-tuple>:
__metaclass__ = <metaclass>
<block>

metaclasses could be supported by using the metaclass as the callable
in a make statement::

make <metaclass> <name> <bases-tuple>:
<block>

Removing the ``__metaclass__`` hook would simplify the BUILD_CLASS
opcode a bit.
Removing class statements in Python 3000
----------------------------------------

In the most extreme application of make statements, the class
statement itself could be deprecated in favor of ``make type``
statements.
References
==========

... [1] Michele Simionato''s original suggestion
(http://mail.python.org/pipermail/pyt...er/057435.html)

... [2] Namespace-based property recipe
(http://aspn.activestate.com/ASPN/Coo.../Recipe/442418)

... [3] Make Statement patch
(http://ucsu.colorado.edu/~bethard/py...tatement.patch)

... [4] Instances of create in the stdlib
(http://mail.python.org/pipermail/pyt...il/335159.html)

... [5] Instances of create in Zope+Plone
(http://mail.python.org/pipermail/pyt...il/335284.html)
Copyright
=========

This document has been placed in the public domain.


...
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:

推荐答案

修订版：45366

最后修改：

Last-Modified:

日期：2006-04-13 07：36：24 - 0600（2006年4月13日星期四）

Date: 2006-04-13 07:36:24 -0600 (Thu, 13 Apr 2006)

这篇关于PEP 359：“制造”声明的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！