PEP：专业化语法 [英] PEP: Specialization Syntax

问题描述

大家好，我想知道你对这个PEP有什么看法。任何评论

欢迎（甚至关于英语错误）。


PEP：XXX

标题：专业化语法

版本：$修订：1.10 $

最后修改日期：$ Date：2003/09/22 04:51:49 $

作者：Nicolas Fleury< nidoizo at gmail.com>

状态：草稿

类型：标准跟踪

内容类型：text / plain

创建时间：2005年7月24日

Python版本：2.5

后历史：

摘要

这个PEP在Python中提出了一种语法来执行

中所称的文档specialization。它包含多个

提案：

- 使用__specialize__方法扩展方括号语法以允许完整的调用语法，

，类似于__call__

方法。

- 扩展函数定义语法以允许专门化

函数。

- 参数化类型。

动机


在他有争议的博客文章添加可选的打字到

Python - 第二部分中[1]，Guido Van Rossum介绍了参数化类型的想法

。在Python中。这个命题是使用[方括号]而不是< pointy ones>使用__getitem__方法允许

原型设计。但是，__ getitem__

方法不够灵活。它不支持关键字

参数，并且使用多个和默认参数可能会很痛苦，因为收到的唯一参数是一个元组。如果可以允许元组作为第一个

参数，则调用

也可能容易出错。这个PEP建议增强方括号语法

以允许使用括号的全调用语法。


请注意，Guido暂时放弃了参数化的想法

类型在以下博客条目[2]中。这个PEP仅作为最后一步介绍

参数化类型，并且更多地关注

，它们具有原型化的语法。这个PEP也可以作为一个独立讨论专业化特征的地方。


术语专业化在该文件中使用，因为

"参数化函数"听起来像是已经可用的

功能。正如Guido指出[1]，泛型既不是一个好的

术语。专业化就是从C ++借来的一个术语。

这个术语并不完美，因为它指的是将参数传递给参数化类型的行为。 （或函数）

使其可用，并且仍然必须找到一个术语来描述

unspecialized类型或功能。


这个PEP的另一个动机是在Python中频繁使用

函数来创建函数。这种模式通常用于创建回调函数和装饰器，只能命名这些。

然而，创建和使用的事实都是使用

括号可能令人困惑。此外，程序员最终命名

两个函数，当只创建一个函数时，名称和

创建的函数正在完成工作。一些程序员最终将
命名为创建函数，使用他们想要的名称
给创建的函数，使用
$ b $混淆更多代码它。为了解决这种情况，本PEP提出了

函数特化的语法。

__specialize__特殊成员函数。


第一个元素这个提议是增加了

__specialize__特殊成员函数。 __pecialize__

函数可以与__call__具有相同的签名。当

定义时，__ getitem__的定义没有效果，而是将调用

__specialize__。


语言语法是扩展为允许关键字参数

且没有参数。例如：


class MyObject（object）：

def __specialize __（self，a = 4，b = 6，* args，** kwargs）：

通过


obj = MyObject（）

obj [b = 7，a = 8，c = 10]

obj []


注意，当__specialize__被定义时，__ setitem __，

__getslice__和__setslice__仍然像以前一样使用。

专业化装饰者


为了解释本PEP中提出的语法，使用以下

装饰器：

class专业化师：

def __init __（self，callableObj）：

self.callableObj

self .__ name__ = callableObj .__ name__

def __specialize __（self，* args，** kwargs）：

self.callableObj（* args，** kwargs）


def specializer（callableObj）：

返回Specializer（callableObj）


它需要一个可调用的并且可以用方括号调用

代替。

功能专业化


Python中常见的模式是使用函数创建

另一个函数：


def getMember（object）：

return getattr（object，memberName）

return getMember


foo（makeGetMemberFunc（''' xyz''））


这个提议的第二个要素是添加一个语法，所以

可以替换上一个例子：


def getMember [memberName]（object）：

返回getattr（object，memberName）


foo（getMember ['' xyz'']


相当于：


@specializer

def getMember（memberName）：

def getMember（对象）：

返回getattr（对象，memberName）

返回getMember


foo（getMember [''xyz'']）

课程专业化


此提案的最后一个要素是添加语法以传递

类的参数创作：


类列表[ElementType = object]（列表）：

...


这样会相当于：


@specializer

def List（ElementType = object）：

class List（list）：

...

返回列表


请注意，在

继承之前插入了附加语法，与最初提出的不同[1]。

原因是继承可能需要专门化

参数，使用参数更直观

介绍后：


class MyList [ElementType = object]（List [ElementType]）：

...

向后兼容性


这三个命题是向后兼容的。

公开问题


而不是添加a__specialize__方法，__ getitem__

方法可以更改为允许其他签名：


def __getitem __（self，* args，** kwargs）:. ..


其他方括号的运算符是否应该用于

专业化？

参考文献


[1]为Python添加可选的静态类型 - 第二部分，

Guido van Rossum
http://www.artima.com/weblogs/viewpost.jsp?thread=86641


[2]可选静态打字 - 停止火焰！，Guido van Rossum
http://www.artima.com/weblogs/viewpost.jsp?thread=87182

版权


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

Hi everyone, I would to know what do you think of this PEP. Any comment
welcomed (even about English mistakes).

PEP: XXX
Title: Specialization Syntax
Version: $Revision: 1.10 $
Last-Modified: $Date: 2003/09/22 04:51:49 $
Author: Nicolas Fleury <nidoizo at gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 24-Jul-2005
Python-Version: 2.5
Post-History:
Abstract

This PEP proposes a syntax in Python to do what is called in
this document "specialization". It contains more than one
proposal:
- Extend square brackets syntax to allow a full call syntax,
using a __specialize__ method, similarly to the __call__
method.
- Extend function definition syntax to allow specialization
of functions.
- Parameterized types.
Motivation

In his controversial blog entry "Adding Optional Typing to
Python -- Part II" [1], Guido Van Rossum introduced the idea
of "parameterized types" in Python. The proposition was to
use [square brackets] rather than <pointy ones> to allow
prototyping with __getitem__ method. However, the __getitem__
method is not flexible enough. It doesn''t support keyword
arguments and using multiple and default arguments can be pain,
since the only argument received would be a tuple. Calling
can also be error-prone if a tuple can be allowed as a first
argument. This PEP proposes to enhance square brackets syntax
to allow full-call syntax as with parenthesis.

Note that Guido dropped the idea, for now, of parameterized
types in a following blog entry [2]. This PEP introduces
parameterized types only as a last step, and focus more on
having a syntax to prototype them. This PEP can also serve
as a place to discuss to feature of specialization independently.

The term "specialization" is used in that document because
"parameterized functions" would sound like an already available
feature. As Guido pointed out [1], "generic" is neither a good
term. Specialization is a term in that case borrowed from C++.
The term alone is not perfect, since it refers to the action of
passing arguments to a "parameterized type" (or function) to
make it usable and a term must still be found to describe the
"unspecialized" type or function.

Another motivation to this PEP is the frequent usage in Python
of functions to create functions. This pattern is often used
to create callback functions and decorators, to only name these.
However, the fact that both the creation and the use is using
parenthesis can be confusing. Also, a programmer ends up naming
two functions, when only the creating one is called by name and
the created one is doing the job. Some programmers ends up
naming the creating function with the name they would want to
give to the created function, confusing even more the code using
it. To fix this situation, this PEP proposes a syntax for
function specialization.
__specialize__ Special Member Function.

The first element of this proposal is the addition of the
__specialize__ special member function. The __specialize__
function can have the same signatures as __call__. When
defined, the definition of __getitem__ has no effect, and
__specialize__ will be called instead.

The language grammar is extended to allow keyword arguments
and no arguments. For example:

class MyObject(object):
def __specialize__(self, a=4, b=6, *args, **kwargs):
pass

obj = MyObject()
obj[b=7, a=8, c=10]
obj[]

Note that when __specialize__ is defined, __setitem__,
__getslice__ and __setslice__ are still used as before.
The specializer Decorator

To explain the syntaxes proposed in this PEP, the following
decorator is used:

class Specializer:
def __init__(self, callableObj):
self.callableObj
self.__name__ = callableObj.__name__
def __specialize__(self, *args, **kwargs):
self.callableObj(*args, **kwargs)

def specializer(callableObj):
return Specializer(callableObj)

It takes a callable and make it callable with square brackets
instead.
Function Specialization

A common pattern in Python is to use a function to create
another function:

def makeGetMemberFunc(memberName):
def getMember(object):
return getattr(object, memberName)
return getMember

foo(makeGetMemberFunc(''xyz''))

The second element of this proposal is to add a syntax so
that the previous example can be replaced by:

def getMember[memberName](object):
return getattr(object, memberName)

foo(getMember[''xyz''])

which is equivalent to:

@specializer
def getMember(memberName):
def getMember(object):
return getattr(object, memberName)
return getMember

foo(getMember[''xyz''])
Class Specialization

The last element of this proposal is to add a syntax to pass
arguments to class creation:

class List[ElementType=object](list):
...

This would be the equivalent to:

@specializer
def List(ElementType=object):
class List(list):
...
return List

Note that the additional syntax is inserted before the
inheritance, different than what was initially proposed [1].
The reason is that inheritance can need the specialization
arguments, and it is more intuitive to use an argument
after its introduction:

class MyList[ElementType=object](List[ElementType]):
...
Backward Compatibility

The three propositions are backward compatible.
Open Issues

Instead of adding a __specialize__ method, the __getitem__
method could be changed to allow additional signatures:

def __getitem__(self, *args, **kwargs): ...

Should other operators that square brackets be used for
specialization?
References

[1] Adding Optional Static Typing to Python -- Part II,
Guido van Rossum
http://www.artima.com/weblogs/viewpost.jsp?thread=86641

[2] Optional Static Typing -- Stop the Flames!, Guido van Rossum
http://www.artima.com/weblogs/viewpost.jsp?thread=87182
Copyright

This document has been placed in the public domain.

推荐答案

修订版：1.10

Last-Modified：

Last-Modified:

日期：2003/09/22 04:51:49

Date: 2003/09/22 04:51:49

这篇关于PEP：专业化语法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！