更新pre-PEP：create语句 [英] updated pre-PEP: The create statement
问题描述
我已根据comp.lang.python上的一些评论更新了PEP。
最新版本仍在：
http：// ucsu .colorado.edu / ~bethard / py ... statement.html
在这篇文章中，我特别要求对Carl Banks的观点进行评论
（现在在开放问题下讨论过），询问是否更好地将
的创建语句翻译成：
< ;名称> =< callable>（"< name>"，*< tuple>，**< namespace>）
而不是当前：
< name> =< callable>（"< name>"，< tuple>，< namespace>）
前者允许将create语句应用于更多种类
的callables;后者与班级陈述保持更好的平行。
PEP：XXX
标题：创建声明
版本：$修订版：1.4 $
最后修改日期：$ Date：2003/09/22 04:51:50 $
作者：Steven Bethard< st ***** *******@gmail.com>
状态：草稿
类型：标准跟踪
内容类型：text / x -st
创建时间：2006年4月5日
Python版本：2.6
历史后：2006年4月5日
摘要
========
这个PEP提出了类声明语法的概括，
``create``语句。建议的语法和语义并行
类定义的语法，所以::
create< callable> <名称> <元组>：
< block>
被翻译成作业::
<名称> =< callable>（"< name>"，< tuple>，< namespace>）
其中``< namespace>``是创建的dict通过执行``< block>``。
PEP基于Michele Simionato在
python-dev列表中的建议[1] _。尼克建议使用``create``关键字
Coghlan。
动机
==========
类语句为Python提供了两个不错的工具：
（1）它们是创建命名空间的标准Python方法。
执行类主体中的所有语句，并将生成的
本地名称绑定作为dict传递给元类。
（2）他们通过允许创建
类来知道它被分配的名称来鼓励DRY（不要重复自己）。
因此在一个简单的类声明如::
class C（object）：
x = 1
def foo（self）：
返回''bar''
元类（``type``）被称为::
C = type（''C''，（object，），{''x''：1，''foo''：< function foo at ...>}）
类声明只是ab的语法糖ove赋值
声明，但显然是一种非常有用的语法糖。它
不仅避免重复C`，而且还简化了dict的创建，允许它表示为一系列的
语句。
从历史上看，类型实例（也就是类对象）一直是
唯一有这种语法支持的对象。但是其他
种类的对象可以从这种支持中受益。例如，
属性对象有三个函数参数，但因为
属性类型不能传递给命名空间，所以这些函数虽然与b
相关只有属性，必须在它之前声明然后
作为参数传递给属性调用，例如::
class C（object）：< br $> b $ b ...
def get_x（个体经营）：
...
def set_x（个体经营）：< br $> b $ b ...
x =属性（get_x，set_x，...）
有一些食谱[2] _试图解决这个
行为，但是使用新的create语句（以及适当的
属性定义），getter和setter函数可以是
在属性的命名空间中定义，如::
class C（object）：
...
创建属性x：
def get（self）：
...
def set（self）：
...
这种属性可定义的定义ld就像::
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）
当然，属性只是其中之一
create语句的许多可能用法。 create语句在基本上任何名称与命名空间关联的
情况下都很有用。因此，对于
示例，可以简单地创建子模块::
创建模块mod：
"这将创建一个名为mod的子模块，其f1函数为
def f1（）：
...
和命名，可以创建像XML文档这样的嵌套层次结构
like ::
创建ETobject html：
" ;此语句将生成一个ElementTree对象
创建ETobject头：
生成头部
...
创建ETobject正文：
生成正文
...
如果Python获取接口，给定一个可调整的适当定义的接口，可以通过语法::
创建界面C（...）：
...
这意味着接口系统就像那样Zope不会再延长
必须滥用类语法来创建正确的接口
实例。
规格
=============
Python将翻译一个创建语句::
create< callable> <名称> < tuple>：
< block>
进入作业::
< name> =< callable>（"< name>"，< tuple>，< namespace>）
其中``< namespace>``是创建的dict通过执行``< block>``。
``< tuple>``表达式是可选的;如果不存在，将假设一个空元组
。
实现这些语义的补丁可用[3] _。
create语句引入了一个新关键字``create``。因此，在
Python 2.6中，必须使用
``从__future__ import create``语句启用create语句。
打开问题
===========
``create``关键字是否会破坏太多代码？由Michele Simionato [4] _对标准库进行的调查显示，一些小的
破损 - 大约8个实例。特别是，imaplib.IMAP4
对象暴露了一个``create（）``方法，这可能会有问题。
是否有更好的关键字用于声明？
而不是遵循名称的类声明先例，元组
和命名空间参数，是否应该传递函数\ * args和
\ * \ * kwargs参数？这将允许像::
这样的东西创建dict键映射：
A = 1
B = 2
并且会简化新的属性定义（实际上，
当前属性签名根本不需要改变）。但是，
这会严重破坏与类语句的并行。
可选扩展
=========== ========
删除create关键字
------------------ -------
有可能删除create关键字，以便这样的
语句将以调用的callable开头，例如：
模块mod：
def f1（）：
...
def f2（ ）：
...
界面C（...）：
...
然而，这可能会增加语法的复杂性和
到目前为止我（Steven Bethard）还没能实现这个功能
关键字。
删除Python 3000中的__metaclass__
-------------------------- -----------
作为其一般性的副作用，创建语句大多是
消除了对`类中的`__metaclass__``属性
对象。因此在Python 3000中，而不是::
class< name> < bases-tuple>：
__metaclass__ =< metaclass>
< block>
metaclasses可以得到以下支持：在创建语句中使用元类作为可调用的
::
create< metaclass> <名称> < bases-tuple>：
< block>
删除``__metaclass__``钩子会简化BUILD_CLASS
操作码。
删除Python 3000中的类语句
------------------- ---------------------
在创建语句的最极端应用中，类
语句本身可以弃用，以支持``create type``
语句。
引用
======= ===
... [1] Michele Simionato的原始建议
（ http://mail.python.org/pipermail/pyt...er/057435.html ）
... [2]基于命名空间的属性配方
（ http://aspn.activestate.com/ASPN/Coo.../Recipe/442418 ）
...... [3]创建统计补丁
（ http：// ucsu.colorado.edu/~bethard/py/create_stmt.patch ）
... [4]在stdlib中创建的实例
（ http://mail.python.org/pipermail/ pyt ... il / 335159.html ）
版权
=========
本文档已被置于公共领域。
...
本地变量：
mode：indented-text
indent-tabs-mode：nil
sentence-end-double-space：t
fill-column：70
结束：
I''ve updated the PEP based on a number of comments on comp.lang.python.
The most updated versions are still at:
http://ucsu.colorado.edu/~bethard/py..._statement.txt
http://ucsu.colorado.edu/~bethard/py...statement.html
In this post, I''m especially soliciting review of Carl Banks''s point
(now discussed under Open Issues) which asks if it would be better to
have the create statement translated into:
<name> = <callable>("<name>", *<tuple>, **<namespace>)
instead of the current:
<name> = <callable>("<name>", <tuple>, <namespace>)
The former allows the create statement to be applied to a wider variety
of callables; the latter keeps a better parallel with the class statement.
PEP: XXX
Title: The create statement
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
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
Abstract
========
This PEP proposes a generalization of the class-declaration syntax,
the ``create`` statement. The proposed syntax and semantics parallel
the syntax for class definition, and so::
create <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. The ``create`` keyword was suggested by Nick
Coghlan.
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 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 create statement (and an appropriate
definition of property), the getter and setter functions can be
defined in the property''s namespace like::
class C(object):
...
create 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
create statement. The create statement is useful in essentially any
situation where a name is associated with a namespace. So, for
example, sub-modules could be created as simply as::
create module mod:
"This creates a sub-module named mod with an f1 function"
def f1():
...
and named, nested hierarchies like XML documents could be created
like::
create ETobject html:
"This statement would generate an ElementTree object"
create ETobject head:
"generate the head"
...
create ETobject body:
"generate the body"
...
If Python acquires interfaces, given an appropriately defined
``interface`` callable, the create statement can support interface
creation through the syntax::
create interface C(...):
...
which 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 create statement::
create <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 create statement introduces a new keyword, ``create``. Thus in
Python 2.6, the create statement will have to be enabled with a
``from __future__ import create`` statement.
Open Issues
===========
Does the ``create`` keyword break too much code? An investigation of
the standard library by Michele Simionato [4]_ suggests some minor
breakage -- about eight instances. In particular, imaplib.IMAP4
objects expose a ``create()`` method, which could be problematic. Is
there a better keyword for the statement?
Instead of following the class statement precedent of a name, tuple
and namespace arguments, should the function be passed \*args and
\*\*kwargs arguments? This would allow things like::
create dict keymap:
A = 1
B = 2
and would simplify the new definition of property (in fact, the
current property signature shouldn''t need to change at all). However,
this would pretty severely break the parallel with class statements.
Optional Extensions
===================
Remove the create keyword
-------------------------
It might be possible to remove the create keyword so that such
statements would begin with the callable being called, e.g.:
module mod:
def f1():
...
def f2():
...
interface C(...):
...
However, this would probably 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 create 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 create statement::
create <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 create statements, the class
statement itself could be deprecated in favor of ``create 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] Create Statement patch
(http://ucsu.colorado.edu/~bethard/py/create_stmt.patch)
... [4] Instances of create in the stdlib
(http://mail.python.org/pipermail/pyt...il/335159.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
End:
推荐答案
修订版：1.4
最后修改：
Last-Modified:
日期：2003/09/22 04:51:50
Date: 2003/09/22 04:51:50
这篇关于更新pre-PEP：create语句的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
